[cairo] W32: Drawing globally-transparent stuff with cairo

[LRN]

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

On 06.04.2014 13:43, LRN wrote:
> On 30.03.2014 2:29, LRN wrote:
>> On 27.03.2014 19:54, LRN wrote:
>>> I've been trying to somehow hack GTK to have RGBA GdkWindows, 
>>> with mixed results so far (i either get massive alpha
>>> corruption, or crash pixman inside bitblt).
> 
>>> Decided to take a step back and see if i can make it work 100%
>>>  correctly with just GDI & cairo. Turns out, i can't.
> 
>>> I've attached an example, compile with gcc main.c -o main.exe 
>>> -I/mingw/include/cairo -lcairo -lgdi32 -ldwmapi
> 
>>> It draws two gradients - one transparent, and one opaque. 
>>> Transparency only works when window is invalidated and
>>> repainted (such as when it is obscured by another window and
>>> later shown again).
> 
>>> The problem is most likely W32-specific, and not directly
>>> related to cairo, but i simply can't find what is wrong :(
> 
> 
>> I'd like to thank everyone for the help.
> 
>> The problem was mostly in W32 display config (glass transparency 
>> not enabled).
> 
>> I'm now convinced that the rest of my problems are due to a bug
>> in cairo/pixman.
> 
>> GTK bug tracking this is: 
>> https://bugzilla.gnome.org/show_bug.cgi?id=727316
> 
> 
> 
> Traced inaccessible memory to _cairo_image_surface_map_to_image(), 
> which gives pixman a pointer and claims that it points to image
> data of *width*, *height* with a *stride* - which turns out to be
> false.
> 

Tried to clamp width and height of the image that
_cairo_image_surface_map_to_image() creates (i.e. instead of
extents->width i tried to give it MIN(other->width - extents->x,
extents->width), same for height). Cairo stopped crashing, but GTK
windows are not drawn completely (they are cut on the bottom and on
the right edge; and since there are still pixels out there, which
don't get re-drawn, they retain old data, making it obvious that this
clamping is too strict).

This led me to believe that cairo misinforming pixman about image size
is on purpose, and drawing procedures do rely on such behaviour. The
question is, why this only blows for this particular case, and
otherwise worked for everyone just fine?

I couldn't find where to get actual, correct information about true
extents of the memory area to which images point, and without that
this kind of correction can't be implemented.


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

iQEcBAEBAgAGBQJTQUZaAAoJEOs4Jb6SI2CwlBQH/1NtB7Sclca9gEFVUTQhQbg/
VVkCEfMFpYe9QWUGcAAX7dbyfegd+LJwvOMCnRL9haewkuxFIGkk/Jg6QAMjLL2l
okFmXnvxAZd/7YauBT8Rftzh0S8bJ0Xm57AvQGDJYN+rioGgFkten/8CIuWnHkye
20ZfsErSwEv8nY6rUIQJVKKuHTuyjF1/nXz5KmXiRYTB1hSLxD14lhcbLNFONIA/
sNN56Td2jjf5iVmSgx5M/Du+Uy+yR/JKj9+aoaDjVA5AM3RFyVIqMiFLrxL5r4ie
LmNYQZmnDtvncRrLP8t6m6u8F6f8ZXRJEUVJwbSatujxQPMrszCkfQZdm/joXk0=
=LWcP
-----END PGP SIGNATURE-----