Re: W32: Drawing globally-transparent stuff with cairo

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

Uli
-- 
Happiness can't be found -- it finds you.
 - Majic
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo