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

LRN lrn1986 at gmail.com
Thu Apr 17 13:00:50 PDT 2014

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

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
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,
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
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
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
Version: GnuPG v1.4.11 (MingW32)


More information about the cairo mailing list