https://bugs.kde.org/show_bug.cgi?id=511269
--- Comment #2 from Shengyu Qu <[email protected]> --- (In reply to Zamundaaa from comment #1) > Linear doesn't follow human perception at all either, but gamma 2.2 is quite > close to what people expect a percentage level of opacity to look like. > Using linear caused a lot of complaints about things looking bad, in one > extreme case even completely unreadable, and the opacity slider in Konsole > not behaving like expected. > > Consistency between Windows and Plasma is a non-goal, we need consistency > with our own applications and themes. Blending in some gamma space is the > only way to achieve that. > > If we get a Vulkan compute renderer done at some point, we can do custom > blending functions in there, if there's Windows applications that depend on > linear blending. Until we have that and apps can explicitly request a > specific blending space. > > > Also, with the incoming KMS color pipeline API, color blending using linear > > space won't cost as much performance as before. > It only changes when we can use overlay planes, but nothing else about the > performance impact when compositing with the GPU. > > (In reply to Shengyu Qu from comment #0) > > (Off-topic)Also, I'm thinking about whether we should add more detailed > > options than just a "performance/precision" settings, for example, dedicated > > option to enable KMS offload and direct scanout. > We have environment variables for these things, which should be enough for > debugging and working around driver issues. > > About the actual option to do linear blending, I don't think it would be a > good idea. There's basically no reason for anyone to want linear blending, > it only has downsides and would make the code more complicated for no good > reason. Thanks for reply. I have another question: Switching between linear and non-linear would only affect alpha blending? Or other color space operation are also affected? -- You are receiving this mail because: You are watching all bug changes.
