[cairo] A hidden offset for the xlib backend

[Jost Boekemeier]

> perhaps X and Y are just two additional parameters 

If we allow a specific surface type to have a
non-default (non-zero) offset, all the hell breaks
loose if users pass this to the retained mode
implementation. 

The retained mode maintains a "szene graph" and users
feed it with a [(x_off, y_off] . surface) pair to
obtain the part of the szene in a specific (xlib, ps,
...) format.  If one surface has an internal,
non-zero, offset, the result will be completely
different for this surface.

Also I could imagine that people who want to re-use
surfaces ("pooling") might have problems with the
offsets.

If we maintain offsets within cairo, these offsets
should be available for *all* surfaces and we need a
way to query these offsets (a surface pool
implementation might even need to reset the offset).


However, I don't see maintaining offsets outside of
cairo as a problem.  C/Java/Oberon/C# programmers do
this all the time when they access arrays.  Unlike the
Modula programmers they can't simply write 
ar[10000]=0; ar[10000]=0; to clear a two-element array
at position 10000; they have to write 
ar[10000-off]=0; ar[10001-off]=0; instead.

I don't see why this should be a problem for cairo or
gtk users.  

Jost




	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de