Richard Hughes wrote: > On 20 December 2016 at 07:22, Graeme Gill <grae...@argyllcms.com> wrote: >> Or be prepared to re-visit Wayland's fundamental design decisions >> if they turn out to be based on a false premise. > > I don't think that's fair. I think Wayland is the opportunity to upset > the status quo with color management and do correctly what what never > possible with X11.
I think it is fair - a lot of push back is along the lines of "that's impossible - Wayland doesn't work that way", which if taken to a logical conclusion, (maybe) implies that Wayland is incapable of sporting color management. Assumption: "Applications are oblivious to the output their pixels are rendered to" Reality: An application needs to know the output it's pixels land on if it is to present them in the correct output specific colorspace. Assumption: "The compositor is able to do all the transformations necessary to render applications pixels to the output device" Reality: It may not be practical for a compositor to have the color conversion machinery capable of doing the transformations in the manner and to the precision that an application requires. Assumption: "Graphical system API's can be divided into application operational API's, and Management API's. Wayland need only cover the former". Reality: Some graphical functions are both operational for one type of application, and management for other types of applications. Assumption: "All management functions can be incorporated in the compositor" Reality: Some management functions require full blown applications, and can't practically be incorporated in each compositor, nor tailored to each compositor. So if the realities challenge the assumptions, then either clever means need to be invented to get things to work within the assumptions, or the assumptions need to be softened. Saying "it's impossible" doesn't progress things, nor help bring Wayland up to having the capabilities of other existing systems. [ The above of course is, as best I grasp it from preceding conversations. ] > Lets be honest for a moment. How many applications support color > management on the Linux desktop? We're asking application authors to > understand things like blending spaces, source and destination > profiles, vcgt, overlapping windows on different crtc's and horrible > concepts like that. Agreed. Easier to access, and default color management framework is desirable (and for that reason was included in my sketch). But this shouldn't be at the expense of applications that need more than that, nor at the expense of color management applications needed to set things up so that all this can work in the first place. > As a framework guy, _and_ an app developer I just want to tag one > surface with a colorspace and then let the compositor figure out all > the grotty details. And you should be able to. But what about applications that need far more than that ? (Ordinary CMM's of the type that are likely to be practical in a compositor, lack a lot of capabilities that some applications will need). > Anything more and the application author will just > decide it's not worth the bother. To calibrate we just ask for a > surface that's not going to be tampered with, but we don't want to > optimize for this super-uncommon case. I disagree - leave it to be an afterthought, and it will be done badly or left out completely, crippling the practicality of color management for the system. Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel