[cairo] A hidden offset for the xlib backend
otaylor at redhat.com
Sun Sep 5 16:51:21 PDT 2004
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.
> As the cairo transformation does "almost" what you want, is there a reason
> you wouldn't want to expose gdk-specific helper functions for this case? Or
> do you think a hidden transformation capability like this would be more
> generally useful in cairo?
The gap between the Cairo API all working, and having 4 functions
bizarrely misbehave and need a gdk_cairo_*() replacement isn't
a small one. It's a grand canyon.
Or to put it another way, if I can't hide the GDK internal offset, then
I've introduced another coordinate space to my users. And with every new
coordinate space, you lose about a third of your users.
> I can see arguments for rotation, reflection
> and scaling as well at this level, and that seems like a slippery slope...
Nobody's asked for rotation, reflection, or scaling yet... and I doubt
they are nearly as useful. I don't really see the point in rotating,
reflecting, or scaling a pixmap you draw to before drawing it to the
screen. Unlike a translation which has an obvious applicability to
shrinking the size of an intermediate buffer.
Though if you really want to kill this slippery slope, of course, you
could add something like cairo_set_device_matrix() which set a final
matrix that was prepended to the CTM but hidden from the rest of
the public API.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040905/87b1018b/attachment.pgp
More information about the cairo