Re: [GSoC] KWin colour management
Thank you for all this feedback!
Meanwhile I have been documenting myself and looking into relevant
code (and following this thread). I can't argue on the complex
technical issues and decisions.
2012/3/20 Martin Graesslin mgraess...@kde.org:
There is more into it: first of all KWin currently does not distinguish
between
screens during rendering. To properly have screen aware color correction the
complete compositor has to be made screen aware. The repaint loop has to be
split into multiple rendering passes - one for each screen. This is quite a
change in the way how KWin renders, but might be a useful change.
Okay, this would involve complicated changes, consequently it should
be like a separate sub-project. At the moment I don't know well enough
how KWin renders from my limited current understanding of the code,
but there will be enough time to discuss and see how this could be
done. It is good if this change is possible without massive intrusive
modifications throughout KWin.
As a second step all fragment shaders need to be adjusted to do the color
correction. This has to be done extremely efficient. This is a rather critical
code path especially for low-end hardware (think of old Intel GPUs). Given the
constraints of the GPUs a dynamic feature activation is not possible.
I have a rather crazy idea about how to achieve this for *all* of the
fragment shaders without modifying each one. It might be a silly idea,
but it's worth proposing it.
Every one of these fragment shaders respect the following structure:
1. declarations, functions, uniforms, whatever
2. void main() {
3. fragment shader functionality (whatever the shader does)
4. gl_FragColor = some_expression
5. } // closing bracket, end of shader
Now, colour correction would require this gl_FragColor result to be
different, to be altered. If I understand the shader assembly thing in
CompICC, it would be an alpha demultiply, a 3d texture lookup to
correct the color, and an alpha remultiply. Let's assume this code is
kept in a GLSL function, namely vec4 correctColor(vec4 c). This
function will require a sampler3D.
To make the above code do the color correction, we need to do the following:
* insert the sampler3D declaration and the function definition just
before main()
* alter gl_FragColor = some_expression -- gl_FragColor =
correctColor(some_expression)
These alterations are not *that* complicated, and they shouldn't
introduce any strange instabilities. Similar, but simpler alterations
are already made in GLShader::compile() at kwinglutils.cpp around line
295. Colour correction could be easily disabled at this point.
The tricky part is how to know what window / screen we're compiling
the shader for. This can be done with some little complications, maybe
an extra parameter, or some kind of member for GLShader, or some evil
static variable / member.
The advantage is that it avoids modifying all the fragment shaders
everywhere, but it brings these (i hope slight) complications to
GLShader. What do you think about this?
Oh, and what does dynamic feature activation mean? If it means what
I think it means, then it can be handled by the above idea.
What is in general important to know is that we have not had the best
experience with GSoC students doing work on the core of KWin. Given that I
proposed guidelines for future feature additions to KWin by non-core
developers [1].
Those are really strict guidelines, but I guess they are well based
given the past experiences, so I won't complain. There are a couple of
points that this possible project does not appear to respect, but
those are unclear and debatable when applied to this, in my view.
However, it looks to me as if no further significant features can be
added to KWin if you respect all those points by the letter.
Probably the colour correction code can be kept isolated in a couple
of separate files, without interfering much with the normal KWin
workings. This code would be responsible with getting the lookup
textures for the monitors (or screens) and the windows (possibly). It
may turn complicated and large, but at least it would be isolated.
Given recent discussions on this mailinglist about Oyranos and colord I am
very unsure whether I want any color management relevant code in KWin at the
moment. I will definitely not accept any code supporting only one of the two
systems and any additional build or run-time dependency to KWin will not be
accepted.
Alright, so this colord is a must, eventually. I should document
myself about colord too. But at least I could ask not to make it part
of the objectives for the summer.
In general there seems to be agreement that color management has to be done
inside the toolkit/application and not inside the compositor. A fully color
corrected compositor seems feasible to me, but one where some applications
need to start opting-out of being color corrected is nothing I want to see in
KWin as it adds significant complexity and
Re: [GSoC] KWin colour management
I forgot about the KWin ML :(
And I realized the complications for the strange idea regarding
GLShader are not even remotely necessary, bad thinking on my part.
Explanations below.
2012/3/22 Casian Andrei skelet...@gmail.com:
Thank you for all this feedback!
Meanwhile I have been documenting myself and looking into relevant
code (and following this thread). I can't argue on the complex
technical issues and decisions.
2012/3/20 Martin Graesslin mgraess...@kde.org:
There is more into it: first of all KWin currently does not distinguish
between
screens during rendering. To properly have screen aware color correction the
complete compositor has to be made screen aware. The repaint loop has to be
split into multiple rendering passes - one for each screen. This is quite a
change in the way how KWin renders, but might be a useful change.
Okay, this would involve complicated changes, consequently it should
be like a separate sub-project. At the moment I don't know well enough
how KWin renders from my limited current understanding of the code,
but there will be enough time to discuss and see how this could be
done. It is good if this change is possible without massive intrusive
modifications throughout KWin.
As a second step all fragment shaders need to be adjusted to do the color
correction. This has to be done extremely efficient. This is a rather
critical
code path especially for low-end hardware (think of old Intel GPUs). Given
the
constraints of the GPUs a dynamic feature activation is not possible.
I have a rather crazy idea about how to achieve this for *all* of the
fragment shaders without modifying each one. It might be a silly idea,
but it's worth proposing it.
Every one of these fragment shaders respect the following structure:
1. declarations, functions, uniforms, whatever
2. void main() {
3. fragment shader functionality (whatever the shader does)
4. gl_FragColor = some_expression
5. } // closing bracket, end of shader
Now, colour correction would require this gl_FragColor result to be
different, to be altered. If I understand the shader assembly thing in
CompICC, it would be an alpha demultiply, a 3d texture lookup to
correct the color, and an alpha remultiply. Let's assume this code is
kept in a GLSL function, namely vec4 correctColor(vec4 c). This
function will require a sampler3D.
To make the above code do the color correction, we need to do the following:
* insert the sampler3D declaration and the function definition just
before main()
* alter gl_FragColor = some_expression -- gl_FragColor =
correctColor(some_expression)
These alterations are not *that* complicated, and they shouldn't
introduce any strange instabilities. Similar, but simpler alterations
are already made in GLShader::compile() at kwinglutils.cpp around line
295. Colour correction could be easily disabled at this point.
The tricky part is how to know what window / screen we're compiling
the shader for. This can be done with some little complications, maybe
an extra parameter, or some kind of member for GLShader, or some evil
static variable / member.
We don't need to know that! Distinguishing between windows and screen
can be done just by binding different lookup textures, no need for
extra parameters or useless complications. The altered shader just
tries to do colour correction. If it gets a default sRGB-sRGB lookup
texture, then no colour correction. And I think there are many ways to
disable it altogether - something like that kwin_shader_debug
definition.
The advantage is that it avoids modifying all the fragment shaders
everywhere, but it brings these (i hope slight) complications to
GLShader. What do you think about this?
So, minus the complications.
Oh, and what does dynamic feature activation mean? If it means what
I think it means, then it can be handled by the above idea.
What is in general important to know is that we have not had the best
experience with GSoC students doing work on the core of KWin. Given that I
proposed guidelines for future feature additions to KWin by non-core
developers [1].
Those are really strict guidelines, but I guess they are well based
given the past experiences, so I won't complain. There are a couple of
points that this possible project does not appear to respect, but
those are unclear and debatable when applied to this, in my view.
However, it looks to me as if no further significant features can be
added to KWin if you respect all those points by the letter.
Probably the colour correction code can be kept isolated in a couple
of separate files, without interfering much with the normal KWin
workings. This code would be responsible with getting the lookup
textures for the monitors (or screens) and the windows (possibly). It
may turn complicated and large, but at least it would be isolated.
Given recent discussions on this mailinglist about Oyranos and colord I am
very unsure whether I want any
[REVIEW]: plasma-mobile repositories
hi everyone ... the repositories holding the Plasma Active code have been moved into kdereview as plasma-mobile and plasma-mobile-config so as to go through the usual 2 week review period before moving to their permanent home. if there are any question or queries, input or feedback, please don't hesitate :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thursday 22 March 2012 6:25:36 AM Chusslove Illich wrote: Starting with KDE 4.0, i18n() functions act as XML processors under the hood, expecting the strings to be well-formed XML and resolving some tags (KUIT tags) to a target format (HTML or pure text). These KUIT tags include filename, para, emphasis, etc. I would like to drop this support in KDE Frameworks 5.0. There would be a fully automatic conversion script for sources to resolve KUIT tags in existing i18n() calls into appropriate target formats. The reasoning is as follows. Firstly, in the past 4 years, KUIT tags didn't get to be used very much. Only 0.56% of all messages (1144 out of 200,000) contain any. Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances). This means that both original strategic goals were not accomplished: text elements still have different formatting across most of KDE applications (such as whether filenames are singly or doubly quoted, bold, etc.), and translators still have little additional semantic indication of what text placeholders are substituted with. Secondly, XML processing in strings was made somewhat lax, as a compromise between ease of use, mixing with existing markup (Qt rich text), and not changing programming habits. Most conspicuously, string arguments substituted for placeholders are not automatically escaped, e.g. into lt;, which causes silent non-well formedness behind the scene. In the other direction, people also complained about lt; inexpectedly becoming , etc. (i.e. the programmer didn't know about the XML nature of i18n() and doesn't want this at all). Based on these two observations, I myself would drop KUIT and that's it. But there are a few heavy users, and I'd like to know if they would strongly object to this. Among them: KAlarm, Partition Manager, DrKonqi, libkcdraw... One automatic question could be: can we have KUIT as option, default off? In KDE 4 this was not even technically possible, due to one ugly design problem of i18n(), but I plan to deal with this problem in KDE 5; so it should be technically possible. But, given the usage statistics above, I'm not sure if it makes sense spending time on this. (There would also have to be some redesign, making everything stricter, e.g. automatic escaping on substitution and no mixing with Qt rich text. This means that current KUIT users who would like to continue to use it, would have to do some manual checking and modification in existing code.) Do you mean all of KDE SC 5 (eventually)? or just frameworks? Personally, I have put a lot of time and effort into adding KUIT into my projects over the years and think it is a great help, even if just for the developers to understand how the strings are being used. True, the semantic tags are harder to use and understand for me in the more complex cases. Sometimes I'm afraid to touch since I'm not sure the implictions of my change. I'm really surprised at this proposal. I'm not getting what's broken nor what's causing problems.
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thu, March 22, 2012 5:47 pm, Chusslove Illich wrote: [: David Jarvie :] I understand from your email that you are only proposing to remove KUIT semantic tags, not KUIT context markers. Can you confirm this? I confirm. They are used much more than tags, and have no problems on their own; they are simply useful whenever present. They would only have no functional effect any more (this means dropping /format modifier too). The original intention of enabling consistent formatting of displayed text via semantic tags seems a very desirable one. Removing the tags seems to imply that KDE would abandon the aim of presenting a consistent interface for such items. If an inconsistent interface is generally considered acceptable, then I can live with it. But if we really want to try to make these interface elements consistent, we shouldn't drop the existing scheme without first considering what might replace it. Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
[: David Jarvie :] The original intention of enabling consistent formatting of displayed text via semantic tags seems a very desirable one. Removing the tags seems to imply that KDE would abandon the aim of presenting a consistent interface for such items. If an inconsistent interface is generally considered acceptable, then I can live with it. Based on the (lack of) usage so far, I would say that inconsistent UI text markup is considered acceptable. Or at least too small an issue to be worth bothering with. It occured to me that I could examine usage-over-time statistics, since KDE 4.0. Here is the percentage of strings in core (SC) modules containing KUIT markup, in 6-month steps: 2008-01-010.28% 2008-06-010.32% 2009-01-010.36% 2009-06-010.41% 2010-01-010.42% 2010-06-010.41% 2011-01-010.49% 2011-06-010.49% 2012-01-010.60% While there is some rise in usage, I would consider a 0.32% rise in 4 years to support the tolerable inconsistency conclusion above. Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. When KUIT tags are removed on conversion target formats would be heeded, since they are statically resolvable. So one would end up with some strings converting to plain text, and other Qt rich text. In other words, it would become as if these visual formats were used carefully and consistently from the start. [...] if we really want to try to make these interface elements consistent, we shouldn't drop the existing scheme without first considering what might replace it. Even if majority of programmers would rather not bother, I agree that it would be nice to provide for those who would. So, actually, I have considered a lot what the replacement might be, one which would avoid technical issues I observed so far, and provide extra flexibility that I've seen to be needed. I wrote it up in a proposal for Gettext itself, but there was little enthusiasm. The proposal is here: http://nedohodnik.net/gettextbis/. Chapter 4 and section 5.1 deal with markup, and it is easy to extrapolate back to KDE i18n (revert to %1, %2... placeholders, and consider ggettext() = ki18n() and igettext() = i18n()). However, I don't propose implementing this now, for two reasons. First is that it would be some work in absence of significant number of interested people (which, admittedly, usually does not stop me...), and the second is that I have a small hope that in the future we could actually push the full system as proposed :) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part.
Re: Re: Re: [GSoC] KWin colour management
Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Where would be a competing system on Linux? Well, I certainly did not read all of that colord ./. oyranos flamewar on k-c-d where supporters of either basically tagged the other like incapable and/or irrelevant s..tufff, but I as certain did not dream about it. So while this might just have been kindergarten s...tuff about xyz uses mono and we hate mono, I was under the impression that those were conflicting approaches to CM. If it indeed only is about implementation details on the very same protocol, thus whether colord or oyranos is in use does absolutely not make any difference regarding the compositor, I wish apologize and withdraw that particular concern. screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Ok, so let me please complete my former question by its implications: Does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol [...], it will be reduced to sRGB while the application and the screen actually could do WG ... ... unless I suspend compositing or switch to another window manager what, because I'm just a user and don't know what a window manager is, likely means to switch to another DE, because it just works on - let's say - Trinity? We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 Many thanks. But that seams clearly away from per-region opt-out but into per-window opt-out, doesn't cover different screens anyway and require toolkits to colour correct the whole window what -if did not terribly misunderstood- also means that if Qt Gtk+ support such, but TCL/TK does not (just examples here), the result would be that w/ or w/o a color correcting compositor, my Qt Gtk apps just work fine whereas my very important professional offset print preview POPP (tm) tool written in TCL/TK only works WITHOUT such compositor (because the canvas is corrected internally and the buttons are all gray anyway) and fails with one. Is that correct? Cheers, Thomas
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Friday 23 March 2012 19.39.26 Albert Astals Cid wrote: Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. I agree with David here, the fact that people don't use them does not mean we should aim at using them. And people don't use them because most people probably doesn't know, this can be attributed to a lot of things, like for example us not having a proper style guide where you would write Each time a filename appears in an user visible message write filename%1/filename. Other reason is developers not caring about consistency much, we could easily gather some non-hardcore developers to go other the various i18n messages of a given app and fix them. Looking at the numbers I'm not sure your optimism is warrented; this feature has been around for many years and its documented on techbase yet its being used in very very low numbers. (333 times in all of KDE for the filename tag..) Sure, it may be ignorance. Frankly, I didn't know about this feature. The fact that developers didn't know about this feature is just as much education as that they never needed it and asked how to do it. I think its nice to be optimistic and think that we can get people to fix their UIs and suddenly get people to care. But can we be certain enough of succeeding now where we clearly failed before that this is actually worth stopping the innovations that Chusslove is working on? Read those numbers again; its kinda depressing really; Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances). -- Thomas Zander
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
El Divendres, 23 de març de 2012, a les 20:12:53, Thomas Zander va escriure: On Friday 23 March 2012 19.39.26 Albert Astals Cid wrote: Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. I agree with David here, the fact that people don't use them does not mean we should aim at using them. And people don't use them because most people probably doesn't know, this can be attributed to a lot of things, like for example us not having a proper style guide where you would write Each time a filename appears in an user visible message write filename%1/filename. Other reason is developers not caring about consistency much, we could easily gather some non-hardcore developers to go other the various i18n messages of a given app and fix them. Looking at the numbers I'm not sure your optimism is warrented; this feature has been around for many years and its documented on techbase yet its being used in very very low numbers. (333 times in all of KDE for the filename tag..) Sure, it may be ignorance. Frankly, I didn't know about this feature. The fact that developers didn't know about this feature is just as much education as that they never needed it and asked how to do it. I think its nice to be optimistic and think that we can get people to fix their UIs and suddenly get people to care. That's only because we are geeks and don't care if half the time a filename appears as '/home/tsdgeos/foo.txt' or /home/tsdgeos/foo.txt or BOLD/home/tsdgeos/foo.txtBOLD or whatever. In a polished environment this is important. IMHO this is something similar to i18n, needs someone that goes after people and nags them to fix it. But can we be certain enough of succeeding now where we clearly failed before that this is actually worth stopping the innovations that Chusslove is working on? I did not understand that it was stopping any innovation, Chusslove can you clarify if you want to remove them for the sake of simpler code (which I don't say it's unimportant) or because they create problems with other features you are developing? Read those numbers again; its kinda depressing really; Yes, they are, but to be honest noone pushed for them, what you expected? Cheers, Albert Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances).
Re: Re: Re: [GSoC] KWin colour management
Am 23.03.12, 17:10 +0100 schrieb Thomas Lübking: Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Where would be a competing system on Linux? Well, I certainly did not read all of that colord ./. oyranos flamewar on k-c-d where supporters of either basically tagged the other like incapable and/or irrelevant s..tufff, but I as certain did not dream about it. So while this might just have been kindergarten s...tuff about xyz uses mono and we hate mono, I was under the impression that those were conflicting approaches to CM. That was likely related to Linux CM DB APIs, but not particular to compositor CM. If it indeed only is about implementation details on the very same protocol, Yes, we have seen no other descriptions for a compositor CM protocol. thus whether colord or oyranos is in use does absolutely not make any difference regarding the compositor, I wish apologize and withdraw that particular concern. screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Ok, so let me please complete my former question by its implications: Does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol [...], it will be reduced to sRGB while the application and the screen actually could do WG ... ... unless I suspend compositing or switch to another window manager what, because I'm just a user and don't know what a window manager is, likely means to switch to another DE, because it just works on - let's say - Trinity? sRGB displaying is for many people the it just works. They likely will find sRGB be more relaxing, if they have a wide gamut display. Look at the email threads, where people search for the sRGB emulation mode for these kind of monitors. We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 Many thanks. But that seams clearly away from per-region opt-out but into per-window correct opt-out, doesn't cover different screens anyway and require toolkits to For different screens can be colour corrected through X Color Management, because the output device spaces are known. toolkit means client side. A client can as well be a application. colour correct the whole window what -if did not terribly misunderstood- It is about specifying a per window opt-out or per window source colour space. A compositor can still apply different per monitor colour conversions. also means that if Qt Gtk+ support such, but TCL/TK does not (just examples here), the result would be that w/ or w/o a color correcting compositor, my Qt Gtk apps just work fine whereas my very important professional offset print preview POPP (tm) tool written in TCL/TK only works WITHOUT such compositor (because the canvas is corrected internally and the buttons are all gray anyway) and fails with one. Your POPP (tm) tool written in TCL/TK will hopefull adhere to the ICC Profiles in X spec[1]. Otherwise it's behaviour is undefined. Such bug is present in Gimp, when the Use system profile check box is initially not selected. Gimp behaves correctly after enabling this option. kind regards -- Kai-Uwe Behrmann www.oyranos.org [1] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec
Re: [REVIEW]: plasma-mobile repositories
El Divendres, 23 de març de 2012, a les 12:01:04, Aaron J. Seigo va escriure: hi everyone ... the repositories holding the Plasma Active code have been moved into kdereview as plasma-mobile and plasma-mobile-config so as to go through the usual 2 week review period before moving to their permanent home. if there are any question or queries, input or feedback, please don't hesitate :) Please fix i18n :-) Problems i found in a few seconds with a grep shell/widgetsexplorer/kcategorizeditemsviewmodels.cpp has a i18n but the file doesn't seem to be extracted shell/widgetsexplorer/plasmaappletitemmodel.cpp the same components/mobilecomponents/ViewSearch.qml the same And then i stopped looking, please have i18n in mind and once you think you've fixed it tell me again and i'll do an in depth review. Cheers, Albert
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Fri, Mar 23, 2012 at 04:28:52PM +0100, Chusslove Illich wrote: It occured to me that I could examine usage-over-time statistics, since KDE 4.0. Here is the percentage of strings in core (SC) modules containing KUIT markup, [...] 2012-01-010.60% i would find this number way more helpful if it gave the percentage of strings with markup only amongst strings which have placeholders, as that is by far the most interesting target group. I have a small hope that in the future we could actually push the full system as proposed :) i wouldn't set the hopes too high. while the system is certainly well thought out, it isn't such a spectacular improvement (as far as the average dev is concerned) that you'd have much of a chance to stand against the momentum of the solutions the various communities have. it's way more likely that you gain traction when you optimize for minimal migration pain in a community which is actually in search of a solution. the next qt contributor summit is in only two months. how about another trip to berlin? ;) p.s.: i still have your epic mails in my inbox, and they perfectly serve the purpose of giving me a bad conscience about still not having answered them properly. let alone your paper. :}
Re: Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Friday, March 23, 2012 08:12:53 PM Thomas Zander wrote: Read those numbers again; its kinda depressing really; I don't have numbers but almost nobody is taking close care of accessibility when developing applications, should be removed it? no we do not. I think that this feature, as Albert said is something that we should promote and try to get people to use them. What we can do thuough is break compatibility and implement them in some other way since their usage is so low.
