[cairo] A hidden offset for the xlib backend
spitzak at d2.com
Tue Sep 7 13:06:45 PDT 2004
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
More information about the cairo