[cairo] [PATCH 1/3] Enlarge fallback surface

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17.04.2014 14:36, LRN wrote:
> On 17.04.2014 13:44, Uli Schlachter wrote:
>> On 17.04.2014 11:06, LRN wrote:
>>> Signed-off-by: Massimo Valentini <mvalentini at src.gnome.org>
>>> 
>>> --- src/win32/cairo-win32-display-surface.c |    8 ++++---- 1 files
>>> changed, 4 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/src/win32/cairo-win32-display-surface.c
>>> b/src/win32/cairo-win32-display-surface.c index 5ecdbee..965f2c4
>>> 100644 --- a/src/win32/cairo-win32-display-surface.c +++
>>> b/src/win32/cairo-win32-display-surface.c @@ -455,17 +455,17 @@
>>> _cairo_win32_display_surface_map_to_image (void
>>> *abstract_sur surface->fallback = 
>>> _cairo_win32_display_surface_create_for_dc (surface->win32.dc, 
>>> surface->win32.format, -							surface->win32.extents.width, -
>>> surface->win32.extents.height); +							surface->win32.extents.x +
>>> surface->win32.extents.width, +							surface->win32.extents.y +
>>> surface->win32.extents.height);
>> 
>> Can you explain (in the commit message) *why* this is necessary?
> 
> No, not really, since i am not the author of the patch. You may be able to
> get some info from [1] and bug 53121.
> 
>> 
>> This function is asked to create a surface covering the extents
>> "extents". Apparently some caller is mis-using the returned surface and
>> uses it outside of these extents. That sounds like a bug elsewhere.
> 
> That is certainly a possibility. Problem is, no one was able to find
> *where* that "elsewhere" is.
> 
> In my case this bug surfaced (no pun intended) because a switch to RGBA
> pixel format forced cairo to use fallback blitting functions instead of
> native W32 ones, which seem to be able to correctly restrain themselves
> and not write outside of the surface memory region (unlike fallback
> functions, which just do what the caller asks them to). So my guess is
> that "elsewhere" is somewhere inside cairo-w32 backend.
> 

Yes, this looks to be the case.

I've tried the testcase from 53121, but it just worked for me and never crashed.
Maybe i was doing something wrong, the reporter didn't elaborate.

Then i turned back to GTK, which crashes reliably. Tried different cairo
versions.

Turns out, applying the RGBA patch to 1.11.2 doesn't make it crash, while 1.11.4
crashes just like 1.12.x do.
Sadly, this is all tangled with fallbacks.

In 1.11.2 there were no fallbacks, and W32 backend claimed to support everything
(blitting, blending), and BitBlt & AlphaBlend were used. Enabling ARGB32 in
1.11.2
works, but not quite - either BitBlt/AlphaBlend don't work with alpha values
correctly, or cairo doesn't do the right thing, but image is rendered in a weird
way (color value is tied to transparency). I've seen that in 1.12.x as well,
when
i've tried to make it use BitBlt and AlphaBlend.

After 1.11.2 there was a number of transitional commits when cairo didn't
work at
all (backend->paint was NULL and cairo just crashed), until finally in
ae3319890eacd1c8282ca6df7b263ac74abb5f8d w32 backend was updated. Enabling ARGB32
windows at this point crashes cairo, and this persists into 1.11.4 and 1.12.x.

So my guess is that W32 backend have *always* been kind of broken. It relied on
BitBlt not crashing when told to operate past surface memory region bounds,
and this never ever worked with fallback compositor. It's just that RGBA windows
are the first thing that seems to reliably make cairo use fallback compositor on
W32 surfaces.

This can be hacked around (this patch), or someone will have to figure out what's
wrong with W32 blitting and blending functions, or someone will have to fix w32
backend to not to draw past the surface memory (i think the way to do this is to
replace w32 compositor routines with dummies that return "unsupported" status,
which will enable massive fallback use; then make sure things work with
fallbacks,
and enable w32 compositor again). Or change pixman surfaces in such a way that
they track actual size of the memory they point to (vs the size they've been
told
to operate on), and are able to avoid going past the bounds.

At least that's how i see it.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJTUDLxAAoJEOs4Jb6SI2Cwil4IAKmJlp/GjETYB6Pc7wQikQQl
Qco/Q32MVoUToOqcTvvrU37C2tQJAvT+QRWeta+jZzzr4Zg7M4dp15Y6ekPTjkTU
ruk+PeF/BIF2bjVXz5Yn2Hv3O+M1yxYD8UWfWPjItHxxxUVWskAS8fBlrb0I/iHs
guF4nd8NcR5rSBmayQnUToS5bzW0Dkvh7V+qnTTqJHsprnpVXavilAQpt7PRP/my
eNYoRXAFMUi4RrjZ7hqDkJHWyQMY+rpqaENQ5A0Zj5V+VeZP7oykw+YhLb197rFQ
Tg3JsHRA+v6rZ8c6WqH+kZ/wtrhCu8LyG2Zeszj7GjpQvfjvULY7EOq7mqunbc0=
=hLBC
-----END PGP SIGNATURE-----