18 Replies to “This week in KWin (2012 week 44, 45)”

1. funny that linux does feature freezes… and git was arguably created to service linux. given cheap branching and good merges… perhaps your workflow could use improvement? I recommend anyone that hasn’t read git help workflows read it.

   1. Linux uses a merge window which is something different than a feature freeze. It’s the end of the merge window and not a feature freeze.

2. I am curious, can you explain in more detail or point to a RR or commit what caused the issues with Mesa 9?

   1. 
commit 6cf057777555a5d0c834de3a0165a62916cf3b40
Author: Fredrik Höglund
Date: Tue Oct 30 18:20:00 2012 +0100

      kwin/glx: Avoid MSAA configs in initBufferConfigs()

      It appears that we're accidentally choosing an MSAA config with the
      Intel driver in Mesa 9.0. So change the algorithm to take the values
      of GLX_SAMPLES and GLX_SAMPLE_BUFFERS into account.

      Found by Kenneth Graunke.


3. Martin, is there a way to add smooth scrolling effects(KWin scripts?) to apps that scroll in KDE?
   Or every app has to implement that themselves?

   1. What do you mean by smooth scrolling?

   2. in case you mean scrolling like a page in a web browser: that needs to be done inside the application. To KWin a window is just a texture, the content is unknown.

      1. I went to an IT conference 2 days ago and almost every speaker was presenting on a Mac OS X. I found it pretty nice how every app was using smooth scrolling, even the simplest text editor. Dialog windows, everything was using smooth scrolling, so I thought may be that’s implemented by the Cocoa Framework which the applications use or by the Window Manager.
         Also, a laptop that was using KDE was having problems with multi-monitor support(positioning the image wrongly on the other monitors), I took it personal but that’s another story…

         1. the smooth scrolling is a toolkit feature (so in our case, Qt) and a toolkit can make it easier or harder to achieve. on OS X, it’s pretty easy (free in almost all cases); with Qt it’s a mixed bag. often pretty easy, but not always and with some significant bugs in areas. it is a lot better than it was some years ago, however, and with QML it has become very easy. QWidget based apps still have a struggle in places though.

            1. Yep, in QML you get it for free too 🙂
               But there are so many applications in KDE, it’s pretty hard to implement that or port to QML for every application.
               Thanks for the answer.

4. Always interesting to read this blog but as an (amateur) photographer I have some questions about kwin color management.

   1. How will it handle programs already including their own color management (like digikam, krita, gimp, development versions of firefox, cinepaint, etc)?
   Rational: you don’t want to have digikam apply the profile and then have the profile reaplied by the window manager. And personally have already set up quite a lot of these programs.
   2. I can see why you would choose Oyranos for a window manager but why has there not been looked at a sollution with colord?
   Rational: As somebody who alreayd needed color management I have set up my system with colord since atm it is better supported (and in my eyes a much saner implementations since it does not include a full color conversions which is not needed as said before a lot of applications already include this)

   Also most people will be running with uncalibrated/unprofiled monitors so this project will not really make the situation beter for those people (and no they will not suddenly calibrate their monitors the equipment needed cost at least 100 euro or so), so I personally don’t see the need to have the window manager include color mananged surfaces. Now of course if people want the option I am not stopping them but (unless it is possible to easily disable it for some windows) will probably need to disable it anyway.

   Anyway keep up the good work!

   1. wow that’s quite some question. I’ll try to answer in general and don’t answer the various individual questions.

      First of all I have no idea about color correction at all and the GSoC project has not been hosted by the KDE community and has been mentored by Kai-Uwe – an outsider to KWin. As Kai-Uwe is maintaining Oyranos it explains why it is not a solution with colord.

      I do not know whether it makes sense to have color correction inside the compositor and have also been very sceptical. You can read more about the background in this mailinglist thread. But given that the code is clean enough and will hopefully been maintained I had not seen a reason to block it. We’ll see whether the whole thing makes sense at all.

      1. Thanks for the answer, personally I don’ t think it makes sense to do color management in the compositor (since it does not know what the window is used for and thus is not able to set rendering intent and to do some other tricks that are more usefull if controlled on a per program basis, now in the toolkit it is a different story), but if people really want this and can be disabled I see no reason to complain (to much at least 😉 )

         1. The implemented X Color Management spec allows for communication of applications with the colour server (KolorServer). So opting out of colour management is a requirement to do a lots of things the sane way. Advanced ICC aware applications are completly free to do whatever they want through the X Color Management protocol.

            It is easy to be sceptical. But what alternatives do we have for consistent end-to-end desktop colour management? ICC Colour Management is available on request for a very long time through lcms. But the majority of applications do not care about colour. As a result, the desktop looks inconsistent like patch work. ICC style colour correction in the window manager solves that to a good part.

   2. 1. The X Color Management spec, as implemented by KolorManager for KWin, and the elder ICC Profile in X spec, as used by most ICC aware applications on Linux, integrate very well. Of cause here and there are some bugs around, which need to be reported and then get fixed.

      2. Using the same configurations for ArgyllCMS, Oyranos and colord is a understandable goal. I am working on implementing better support for that.

      Erwin Burema: “Also most people will be running with uncalibrated/unprofiled monitors so this project will not really make the situation beter for those people (and no they will not suddenly calibrate their monitors the equipment needed cost at least 100 euro or so), so I personally don’t see the need to have the window manager include color mananged surfaces.”
      That assumtion is odd. On-the-fly profile generation from the EDID information provided by the monitor is pretty standard on major operating systems including Linux for quite a while, that’s better than nothing. Additionally device vendors provide ICC profiles on CD and users share self made ones for their devices already on Taxi DB. So the cost for a measurement devices is no hurdle for base level colour management any more.

      1. Maybe I don’t have a complete picture of what you can get out of the EDID info from the monitor but I tought that that information was mostly burned into a rom by the manufactor of the monitor and assuming the following:

         1. A manufactor is not going to check every monitor they make so every one will have slight (and sometimes perceptibable) differences but the same profile loaded in EDID
         2. Even LCD monitors will drift over time
         3. Profiles are sensitive to contrast and brightness settings which sometimes get changed by people (due to the surounding lighting of their workplace)

         This will lead into that the EDID information is not reliable (and the same for a profile on a cd) and that using that will not lead to having to monitors looking the same (in fact depending on situation it can make things worse! Especially if LUTs get involved)

         Now having a central place to configure (prefered, sometimes need to change it of course) rendering intent which profiles to load for which devices (and load LUT for screens) is a different matter al togethet (although seeing what is on the openicc site I wonder if things are not a bit overengineered although I am not a software engineer, just a physicist)

         Also (if am not wrong here please correct otherwise) for a lot of things loading the LUT should already improve quite a lot without having to add the full color management infrastructure.

         Anyway if I can turn it of for selected applications (which seems possible) I don’t see a real problem, just higly skeptical if this is really needed. Maybe we should continue this discusion somewhere else tough.

         1. Your points 1 till 3 are all true. However we talk here about the majority of users without the need for colour critical work. So the EDID derived profile is already a big improvement. for them. Note, Firefox generates on Linux since quite some releases those EDID derived ICC profiles itself and uses them to the advantage of its users.

            If there is a bug for ICC profiles and a involved gamma LUT’s please fill it and we can fix that. Normally it should work fine.

            Gamma LUT’s alias VCGT are explained here a bit:
            http://www.oyranos.org/2011/09/colour-correction-concepts-for-monitors/ We see some disadvantages for using calibration on 8-bit per channel pipelines. They cause banding for all applications without any workaround for them.

            I am oy@freenode.net#openicc or just write a blog post and ping me on that.

5. These are nice improvements and I eagerly look forward to upgrading. Window moving, but also desktop effects in general have been quite slow on my machine in kubuntu 12.04 (triple monitor, ati 5850 card) so hopefully it’ll improve things. Thanks for putting in the work! 🙂

Comments are closed.