[cairo] A hidden offset for the xlib backend

[Bill Spitzak]

On Tuesday 07 September 2004 10:46 am, Owen Taylor wrote:

> Remember, "creating a backing pixmap" is just a bit of bookkeeping
> in X. It doesn't cost any more time to allocate megabyte of memory
> than 5 bytes of memory.

I find this hard to believe. Perhaps it can defer allocating the memory until 
the first drawing is done, but it is going to allocate it. And if you change 
the size rapidly and have more than one, you are going to get fragmentation.

> And keeping around a backing pixmap for every window on the screen
> certainly is extremely inefficient... if backing pixmaps are created
> temporarily, then they likely will be allocated in video RAM. If
> backing pixmaps are created permanently, then the first one gets
> the video ram, and the rest are in system ram.

Having only one backing pixmap at a time is interesting and I never 
considered it. Keeping the pixmap allows incremental update but this may not 
be as important as it once was. But certainly Mesa, the XFree86 xdbx 
extension, all this new Composite extension stuff, and also the OS/X and 
Longhorn and even old NeXT implementations allocate an entire off-screen 
image for every window.

> cairo_inverse_transform_point() certainly doesn't produce the desired
> result... say you have button press coordinates ... they are going
> to be relative to the window, not to GTK+'s temporary backing pixmap.

Okay I see now. I'm not sure what you are doing exactly though, it might be 
possible that you could be calling a GTK wrapper function that adds the known 
offsets to the cairo translated position. For mouse events you should use a 
different context that is the actual window, though this won't work for your 
clip-test example.