[Cairo] Color transforms
spitzak at d2.com
Thu Jul 17 12:05:56 PDT 2003
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
More information about the cairo