[cairo] A hidden offset for the xlib backend

[Owen Taylor]

On Tue, 2004-09-07 at 13:05, Bill Spitzak wrote:
> On Sunday 05 September 2004 04:51 pm, Owen Taylor wrote:
> > On Sun, 2004-09-05 at 18:42, Keith Packard wrote:
> > > Around 18 o'clock on Sep 5, Owen Taylor wrote:
> > > > Situation here might be we are exposing a small 100x100 region
> > > > in the middle of a 10,000x10,000 pixel window. The backing
> > > > pixmap is created 100x100 pixels instead of 10,000x10,000
> > > > pixels for obvious performance reasons.
> 
> In FLTK the backing pixmap is the size of the *window*, not the scrollable 
> area. This would avoid this allocation problem, and also avoids destroying 
> and recreating the backing pixmap on every expose, which I suspect is 
> extremely inefficient.

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.

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.

> > The gap between the Cairo API all working, and having 4 functions
> > cairo_set_matrix()/cairo_default_matrix()/cairo_inverse_transform_point()
> > bizarrely misbehave and need a gdk_cairo_*() replacement isn't
> > a small one. It's a grand canyon.
> 
> I don't see that. I feel that drawing code should never be using any of those 
> functions except inverse_transform. And inverse transform *does* produce the 
> desired result!

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. 

To give the concrete case where I first encountered this, my application
was drawing a complex and expensive shape. To do rejection, I computed
the bounding box (in user coordinates; the drawing code had scaled and
translated), and then translated that to the to device coordinates and
compared it to the clip region from event.

I consider this a legitimate use case. cairo_current_matrix(), 
cairo_set_matrix(), and so forth are a little more unusual to need,
but they do come up. Basically, the pixel grid does matter, so
applications sometimes need to work in pixel grid coordinates.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040907/04a9dfd5/attachment.pgp