Am 18.12.2012 06:40, schrieb Bill Spitzak:
On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
Then a client such as gimp could draw all it's display into a single buffer.
To get the different color correction of the center display, it would
declare a subsurface containing this and set it's color correction
differently using the wayland api. This would only allocate one buffer,
which would save memory, but more importantly it should make internal code
in gimp easier as you could work around a toolkit that assumes only one
output buffer.
My approach to color correct rendering in Wayland is to let the
compositor handle it and have the clients simply specify which color
space they are using. Only the compositor can render clients correctly
when they are displayed on multiple monitors (unless we introduce a
way to set a buffer per-output).
Yes this is what I am assuming.
What I am asking is if it makes sense for a client to draw two different color
spaces into the same buffer. The larger area is color space A, and a
rectangular subarea is color space B. It then tells wayland to make the main
window color space A, and then makes a subwindow with the clipped subarea and
tells wayland that it is color space B.
That is how the X Color Management spec implementations communicate
between clients and servers. Take a window handle and tag it with a
region, which in turn points to a ICC profile. I think Martin had a
similar idea to place regions on own textures for KWin some time ago.
The reason is to save buffer space, and also to work around toolkits and
drawing api's where it is a lot more practical to draw everything into the same
buffer.
For this reason Xcm adopted the per region tagging approach. Qt and Gtk
people tould us, they do not like to expose subwindows.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
