[cairo] A hidden offset for the xlib backend

[Bill Spitzak]

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.

> 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!

> > 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!