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

[LRN]

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

On 06.04.2014 16:53, Uli Schlachter wrote:
> On 06.04.2014 14:19, LRN wrote:
>> 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.
> 
> I have no clue about cairo-win32, but you might want to look at 
> these:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=53121 
> https://bugs.freedesktop.org/page.cgi? 
> id=splinter.html&bug=53121&attachment=85688 
> http://lists.cairographics.org/archives/cairo 
> /2013-September/024626.html
> 

http://lists.cairographics.org/archives/cairo/2013-September/024626.html
sounds very much like what i'm experiencing. I did try the patch from
bug 53121, and it appears to be fixing the crash that i've had.

Thank you, Uli, and everyone else who contributed to the discussion.

What are the plans on committing this patch (or fixing the issue in
some other way)?


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

iQEcBAEBAgAGBQJTQVXYAAoJEOs4Jb6SI2CweeIIALSRJ3mluvcfotDeDjsFEhCP
wYIWWCjKUGgfCKVbxU0LJEYiUu6SL34lOYaOBtXlzyXVbt1F5Mz95gWFyBWsUdY0
FlKRlmBOOkMHPD/bH/sT2dTIGohiBoHHRhgB+kaIxpQCXP3A/cLfyR6uH/+BpQed
YzwIPpfGwYx1g2qhgEOcYzy9ISTyvO1tW1JyqHR/K8WYGd8YiKhZCOJSkeuioXUU
XDgbhOcuISJEZqIAT1QfH42d58wSSHC6wnoqchk10lfOyjG4z6ZvxWl2F0Sbsi+F
ZvOELBMoiWwZhDHq+4cSL9nRFu4aRHxoVtyCQ+92Po60LBz+nhZWY8TFQZ3R9oI=
=DHzG
-----END PGP SIGNATURE-----