A KDecoration2 update

Before heading into the weekend I thought about writing a small update about the KDecoration2 status. Since my last blog post I started integrating KDecoration2 into KWin. This was partially easier and partially more difficult than anticipated. Especially ripping out the old decoration code is rather complex. There are quite some design differences which make the transition complex and especially values inside KWin core are using enums defined in the decoration API – e.g. the maximized state is kept as a KDecorationDefines::MaximizedMode. This will need further work to move the enums and so at the moment the old decoration library is still compiled although the library is no longer in use.

Ah that means there is code? Yes, today I pushed the branch as “graesslin/kdecoration2″ into kde:kwin git repository. To give it a proper try you also need the kde:kdecoration (master branch) and kde:breeze also on “graesslin/kdecoration2″ branch. The new decoration API is working quite well and I’m rather satisfied. The memory usage of KWin dropped significantly. In a previous report I mentioned that KWin needs around 200 MB, right now my KWin only needs around 40 MB, the number of open windows is a little bit smaller, but still it shows in the right direction. And that’s without any optimisations. There is still some optimization potential in Breeze (check out our todos, all purple tasks are in Breeze) and in KWin (red tasks). Also a nice improvement is that the window decoration no longer flickers when resizing the window. This is a rather big annoyance of KWin 5.0. I expected that the new API would fix this issue, but seeing it confirmed is really nice :-)

Last but not least the restart of KWin got faster which is a nice improvement for KWin developers, for users it’s not that important. The reason for this is that when we enabled/disabled compositing we recreated the window decorations. So when restarting KWin we first created all windows with their decoration before enabling compositing to just destroy them and create them again (yes it would have been possible to improve it, but it doesn’t hit users). Now with the new API there is no need to recreate the decoration. Only a Renderer is exchanged, but the rendering is delayed till it’s needed.

This screen shot does not only show the new Breeze decoration, but also some new features: when quick tiling a window the borders cornering the screen edges are removed. Also in the preview application one can see that the decoration scales which is nice for high-dpi screens. The decoration API follows the approach Plasma is using.

I have been running a KWin with the new decoration API since Monday, which means we are close to start the review process. But there’s of course still work to be done and I’d appreciate any help. The window tab API is not yet implemented, the configuration module needs adjustments to load and render the new deco and most important we have to port the existing decorations like Oxygen, Aurorae, deKorator and QtCurve. For the last three I want to improve the theme experience by allowing the plugin to say that it supports themes directly in the JSON meta data and point to where to find them. So the configuration module can just show all of them. The trick will be to pass the to be used theme to the factory method (we have a nice QVariantList there which can be used). Also the meta data will make it possible to point to GHNS configuration files so that we can not only download Aurorae themes from the configuration module, but also other themes.

16 thoughts on “A KDecoration2 update”

  1. Please say that DPI scaling is not enabled by default and is anyways possible to be enabled/disabled/

    There is no worse thing than spend money for higher resolution display and only to find that the resolution is useless because scaling.

    Because scaling elements are too large and takes space from content while not offering usually no benefits.

    1. I thought the point of a High DPI display was clarity and detail, not making microscopic text and images. Why would it be sensible to make everything so small only a fraction of the users would find it usable. Not scaling is seen as a bug these days not a feature, I doubt it is going to be that hard to make everything small again.

      1. People should stop using DPI as measurement for quality.

        The resolution is still today the main factor what rules what you can do with computer and how does it look, not DPI what is only outcome from factors of resolution and display surface physical size (resolution = X * Y pixels. physical size X * Y millimeters).

        The purpose to have high resolution is to have more content at once visible and more usable viewing area. Less scrolling and better multitasking.

        The large physical size benefit is to get content larger at shorter distance. Instead bringing small size display very close, we can keep it further and still have larger surface to look. This to help eyes to focus further instead just close.

        The clarity doesn’t come from high pixel density, it comes from clear sharp edges and contrast. That is as well reason why we have two different typefaces, Serif and Sans. Serif has small endings while Sans doesn’t.

        Depending format other is better than another. But humans do not read letters, they recognize shapes. And serif helps to recognize shapes faster, hence makes reading easier and faster than using sans typeface.

        And to make the letter even easier to read, it doesn’t need to be build from 32×16 pixels, as better is when it is just 12×6 pixels.

        Some people are just small-minded for fonts and high DPI that you need to have smoother and higher all the time.

        If they want higher DPI, it is enough they just go and place their display further. From normal 80cm distance it is only required to push to 100cm distance and they magically have higher DPI.

        And I didn’t say that there should not be scaling, only that it should not be default and should be a option for those who doesn’t care clarity and details and content what they pay.

        Otherwise we would still be using a 6-8″ displays that should be enough for everything. But wait, WE ARE! Smartphones and tablets are like computers were at 80’s.
        Today we have 24-30″ displays and they are exactly what people need, to have three or even four web pages open at one time. Have a 8-12 pages open at one time. Have 2-3 videos open at one time. Have a 4-6 photos open at one time.

        What is required for smartphones and tablets and even for laptops (portability, pocketable) isn’t required on workstations where we can have larger displays and actually get more content open at one time and do multitasking easier without interruptions because we need to look a different display or swap between full screen apps blocking the context.

        1. The way DPI scaling works in Plasma Next is that we base all pixel dimensions on the pixel size of the font the user selects. If you increase display DPI, but do not want the UI to appear larger (in terms of pixels), you just need to reduce font point size.

          This should work for icon sizes, spacings, and margins. If anything looks good only with a specific font size, but does not when changing it, then you found a hard-coded pixel size. In that case, please report it as a bug.

          For touch interfaces, Qt allows to configure a separate measurement: the “global strut”. All interactive regions should respect that value, so they could appear larger than the font requires.

        2. If you have 24″-30″ displays @ 1080p-1600p you don’t need to worry about the scaling anyway because that’s not High DPI.

          The scaling is useful for screen sizes that are 2-3x smaller with similarly high resolution. Take Lenovo Yoga Pro as an example which has a 13.3″ screen with a resolution of 3200×1800. Without scaling, you can hardly read anything, not without getting much closer to the screen than normal.

          If you have a desktop setup this won’t effect you.

    2. I have to agree with redsteakraw here. One should see more content when moving to a higher resolution but the main goal is to work with higher detail and comfortability. In other words, don’t over do it on the content.

      1. Higher dpi does not nesesarily mean you want to see more, not at all in my case. I went from a 17″ 1920×1200 screen to a 15″ 3200×1800 screen on my new computer. My eyes can handle to see the same information on the new screen but certainly not more or I will need reading glasses. I would love to have proper working scaling. Right now (on KDE 4) it looking very messy, with some things readable (as I increased font size and icons) but others way to small to read. Some icons/fonts honor the global setting, others not. The window borders, buttons and other visual elements mostly are too small.

        Of course if I had a 40″ screen, I’d love to use the screen size for more information rather than scaling everything.

        “The way DPI scaling works in Plasma Next is that we base all pixel dimensions on the pixel size of the font the user selects.” To me this sounds perfect. As long as it’s adjustable. Because the distance to the screen is a factor in what size you want everything to be. The distance is also influenced by how close your eyes can still focus. Getting really close to 50 now, this distance is increasing…. I prefer to work without reading glasses. I am sure I am not an exception.

        I don’t know if this is too simplistic but would it not be possible to just have a slider for the scaling? Independently of the slider you can still adjust the proportions of the different fonts, icons etc in relation to eachother. But once those are set, (and hopefully the default would be fine for most people) you can adjust the whole thing with the slider.

        Oh, one question, and important one. Right now moving a window from my high DPI laptop screen to the normal DPI external monitor throws everything out. What looks ok on one screen looks completely off on the other. And there is no way to sent font/icon etc. sizes independent for each screen. Would the way Plasma Next works solve this. A screen element would have the same size on each screen, taking into account the size of the screen and its DPI?

        Well, in any case I am really excited with the new Plasma and hope to swith soon! I was running it side by side while that was possible, unfortunately now one has to choose.

        Sincerely,
        Dada Krpa

    3. I don’t think you understand how the DPI scaling works. You set a font, and the rendered size of the font influences the size of other UI elements, so the UI stays in balance overall. This means, that if you set your font to a huge size, UI elements grow with it, if you make it smaller, they’ll shrink. The actual rendered size is a product of the DPI your system has, and the fontsize you’ve set up yourself.

  2. Great work but I have some questions on kdecoration2.

    Does this mean that you will take over as the deKorator maintainer? I believe the scultpure guy is the one who ported deKorator to KWin 4.

    Also, I see that Breeze offers two different implementations in its git repository: “package” and “svg”. “svg” contains two different Aurorae themes, what is “package” for (what do you call this QML-based API)? However, I see that the kdecorcation2 version is written in C++.

    What API does Plastik use and will it also get a port?

  3. Hi! I wonder if kdecoration2 will make use of the upcoming feature of Qt 5.4 which allow QOpenGLContext to adopt existing context. Thanks!

    1. I’m currently considering to delay the integration of kdecoration2 by one KWin release in order to make use of exactly that.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>