[cairo] A hidden offset for the xlib backend
spitzak at d2.com
Tue Sep 7 10:05:46 PDT 2004
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
> 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.
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
> > I can see arguments for rotation, reflection
> > and scaling as well at this level, and that seems like a slippery
> > slope...
As I replied earlier, this is what NeWS did. If this is at all desirable,
maybe it should go all the way. If not, then none of this should be done.
in NeWS the "create a surface" call took no arguments, and used the current
path as a clipping path and remembered the current transformation (and also
remembered the current window/surface as the "parent"). The primary purpose
of the transform was that this same call created windows (they called them
canvases) and thus defined where the window was on the screen. But it could
also be used to rotate or reflect or scale what was drawn and could produce
the offsets stated above. The clip path would produce non-rectangular
windows, including ones with holes in them or disconnected pieces.
There was also a call to take an existing surface and a matrix and apply that
transform to it, this was how you moved windows (integer translations were
special-cased and preserved the contents, all others just created a new blank
one and sent an expose event).
I'm not certain, but I think asking for the current transform gave you the
concatenation including the current window's transformation and also a device
transform that flipped things upside down to the memory-map space. This did
not seem to be a problem.
Now NeWS was written when offscreen memory was extremely expensive, so all
drawing went right to the screen. Keeping the path is probably pointless
today, as better effects like transparent shadows can be done by starting
with a transparent rectangle and drawing what you want. Using the path to
figure out the bounding box us a good idea, however!
More information about the cairo