On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill <grae...@argyllcms.com> said:
.... at this point i'm going to summarize this. this might be more helpful than continuing point by point rebuttals as i sense that there's something missing in this conversation: summary of what i think should be the case (or roughly): 1. if colorspace/profile with buffer from client matches screen compositor SHOULD do nothing with the pixels unless it has to (eg has to blend them with content below or otherwise do effects etc. designated by its layout policy). 2. if null colorspace then compositors generally agree to ALSO not touch pixels and transform them unless it has to blend them etc. like #1, but irrespective of the output 3. if colorspace/profile does NOT match the display then compositor can either a) transform colors to get them correct on another display or b) leave them along and just leave things as they are and perhaps let the user know that the colors for that window/surface may be wrong on that display, or limit the screens that display that buffer based on context. how to clients select a colorspace? compositor sends available colorspaces to client (maybe send per surface actually?). client picks one and renders content given that colorspace/profile and presents that to the compositor for display. compositor may update colorspaces that are available at any time. colorspaces/profiles should be nominal colorspace with a whole bunch of numbers detailing adjustments/mappings to do exact color correction for that colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with different transform constants/gamma lut tables etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel