Juce image pixel data and cairo surfaces

i’m experimenting things with cairo as the backend, as i’m able to use full ARGB window mode in linux when a compositing manager is running (i’m 90% near completion of supporting semi transparent components in linux…).

when rendering a simple alpha rectangle all is working good:

cairo_set_source_rgba (cr, 0.0, 0.0, 0.0, 0.5); cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE); cairo_rectangle (cr, dx, dy, dw, dh); cairo_fill (cr);
but when i try to blit the generate XBitmapImage from the LinuxComponentPeer:

[code] int ls, ps;
uint8* const pixels = myImageToLook->lockPixelDataReadWrite (0, 0, myImageToLook->getWidth(), myImageToLook->getHeight(), ls, ps);

    cairo_surface_t* image =
        cairo_image_surface_create_for_data (pixels,
                                             myImageToLook->isARGB () ? CAIRO_FORMAT_ARGB32 : CAIRO_FORMAT_RGB24,

     cairo_surface_write_to_png (image, "/home/kraken/Desktop/test.png");

    cairo_surface_destroy (image);

    myImageToLook->releasePixelDataReadWrite (pixels);


The problem is that the png generated seems to have something strange, like wrong padding or pixel stride or byte order. I’ve tried with a RGB image instead of an ARGB but the result is the same…

This is what i get:

Can you check if cairo internal pixel storage is equal to the one in juce ? Or i’m doing something wrong ? Any clues ?

Interesting stuff. The image there is what you’d expect if you pass RGB data to a routine that’s expecting ARGB…

yes was that. i was checking useARGBImagesForRendering too prematurely. now the image is rendered correctly.

now something is starting to work, alpha channel and stuff, but i have problems in rendering the correct imagegenerated by juce at the context offset:

[code] // clean the background
cairo_set_source_rgba (cr, 0.0, 0.0, 0.0, 0.0);
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_rectangle (cr, dx, dy, dw, dh);
cairo_fill (cr);

    // sometimes it repaints wrong pieces
    cairo_set_source_surface (cr, jucePeerGeneratedImage, sx, sy);
    cairo_rectangle (cr, dx, dy, dw, dh);
    cairo_fill (cr);



[code] // clean the background
cairo_set_source_rgba (cr, 0.0, 0.0, 0.0, 0.0);
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_rectangle (cr, dx, dy, dw, dh);
cairo_fill (cr);

    cairo_set_source_surface (cr, jucePeerGeneratedImage, sx, sy);
    cairo_surface_set_device_offset (dest, dx, dy);
    cairo_rectangle (cr, 0, 0, dw, dh);
    cairo_surface_set_device_offset (dest, 0, 0);
    cairo_fill (cr);


both produces repaints at the wrong positions…
dx, dy, sx, sy and dw, dh are the same one passed to the blitToWindow function in the XBitmapImage class…

The bitmap isn’t always as big as the window - its origin might not be (0, 0).

i’m on the right direction. thanx for pushing me that way. it is a bit hard to inject in the Windowing code, but finally something is moving along.
apart some repaint glitches (which can be surely spotted after when we’ll clean and organize the sources), the taskbar showing dropshadows buttons (very ugly, i don’t know how to hide a X11 Window from here… investigating) here are the promising conclusions for today:

finally !

tomorrow i’ll try to spot those ugly problems…

Hi Kraken, nice and interresting achievement,

Did you manage to complete the cairo renderer ?
What are the differences from juce’s software renderer ?
Do you know if Glitz can be used for opengl accelerated compositing ?

i’ve got some code here which is working basically, but have little artifacts when doing fast refresh of area to repaint (it think it’s mainly related on how i use the cairo contexts, and i still need to do some refinements).

Anyway i’ve injected the cairo stuff inside the LinuxComponentPeer, i’ve not written a renderer based on cairo, if that was your question.

My main goal is to make use of full ARGB32 Visual in X11 (actually the linux peer in juce supports only RGB24/RGB16), in order to be able to add transparent windows to Desktop when a compositing manager (compiz, xcompmgr, metacity composite, etc) is running.
The drop shadows are explaining well: they are simpler Component added to the desktop with an alpha channel.

I’ve used cairo cause it permit to build a ARGB context directly inside a X11 Window, but i think it will be possible to achieve that also with X11 calls alone.

For glitz that’s a different story, it can be used, but actually in my implementation it will only serve for the final single component image compositing over the window, not for compositing of single Graphics calls.

Now i’m working on it, when i got something interesting i will publish it. But for now, i won’t make a LowLevelCairoRenderer in juce…

ps. Some time ago i’ve made some tests with a OpenGL renderer in juce, but that was quite hard since juce convert all paths to be treated as polygons with different stroke, and that caused bad tessellations problems in opengl (and i’m not a guru in opengl).

ok - thanks for the explanation, and keep your chin up !