[Cairo] Color transforms

[Bill Spitzak]

On Thursday 17 July 2003 01:28 am, Carl Worth wrote:

> The idea I've started developing in the current API is that the device
> is specified by creating a device-specific cairo_surface. Then, one
> can set this as the active surface using cairo_set_target_surface.
> That way, the device is definitely part of the state as you propose.
>
> Also, there are convenience functions cairo_set_target_* that both
> create the device-specific surface and set it as the target.

Sorry my terminology was getting muddled. What you are describing is exactly 
what I was thinking. The "surface" specifies the device. There is no real 
difference between switching windows on the same X display, and switching to 
a window on another X display or to a printer.

> One idea that should be possible with this approach is graphics
> operations using surfaces from separate devices, (think compositing
> images from two different X servers for example). That could be a lot
> of fun if we can get it to work.

That would be a really good idea. It seems this would require Cairo to have a 
"return this area as an image" call. The "composite from A to B" call would 
actually call B's device. It can then detect if A is something it can talk to 
directly, and if not it calls the portable "return this image" call and then 
uses the result as the source.

>  > That wasn't too clear. What I meant is that when you change devices in
>  > Cairo, you should always get the identity transformation and everything
>  > including the clip set to default values.

> I'm not sure this is necessary. I think the semantics would get pretty
> muddled if there were an implicit reset of the graphics state when
> changing devices. The worst part I can think of is that the frontend
> will have to keep some state, (like the clipping path), that may also
> be stored in the backend. That doesn't sound fatal to me.
>
> And if there are efficiency problems, the user can always do the reset
> manually, (or use a separate cairo_state object), or whatever.

The main reason I wanted this is that we can avoid any calls that expand the 
clip region. Changing surfaces and the restore command would be the only ways 
to make the clip region larger. If the clip region is copied from the current 
state then you would have to have a reset-clip call, which will also mean 
that Cairo clipping must be seperated from window-system clipping so you 
cannot draw outside the window by doing the reset call.

The other concern is that this would require all the state to be accessible 
so it can be copied to the new surface. It could also be wasteful if when 
switching surfaces all the state is copied, just to be wiped out by changes 
the program makes immediately after switching to the surface.

If surfaces themselves contain a state (and thus you get this state when you 
switch to the surface) then some of these problems are avoided, but you still 
need a reset-clip call, because restore cannot be used (it would switch you 
back to the previous surface). It also requires all surfaces that exist to 
keep a complete state, which might be a lot more difficult than keeping the 
state for only the "active" surfaces.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com