Posted on by Martin Flöser

Rendering at 60 Frames

Full credits go to Alex Fiestas for complaining about the performance in a way that I wanted to do something about it, instead of being just annoyed and ignoring the comment!

Alex’s complaints got me wondering why we are not able to render 60 frames/second. Each frame should only take 16.67 msec and knowing that our repaint loop is fine, I could not imagine how a frame could take longer to render than the 16.67 msec. Knowing the KWin’s source code pretty well I suspected two parts of the repaint loop to be slow: the method which actually renders each window and our effect chain. The effect chain calls each effect in turn to transform windows. I had an idea to improve the effect chain for quite some time by calling only the currently active effects. That is currently each effect checks first whether it is active and just does nothing. So you basically call all effects again and again and nothing is actually performed except waisting cycles on checking whether it should do nothing (some effects are heavy there).
Of course I do not just optimize without checking if the code needs to be optimized, so I did an analysis of callgrind output and I was surprised. The effect chain was way more heavy than expected. In fact it’s so heavy that the paint method doesn’t matter in comparison. A deeper analysis of the code showed that there is a small bug, which we will fix in 4.7.2 (too late for 4.7.1), so that we can give the benefits as fast as possible to our users. But the real optimization by only calling the active effects will hit only 4.8. After that change the effect chain is no longer visible in the hot pathes of KWin. Also the change immediatelly helped to identify some expensive checks in some effects which are now ensured that they are not called in each frame (unless the effect is active).
After the optimization of the effect chain we are still not yet there and do not reach 60 frames during the animation, but you can really feel the improvements 🙂 Now the paint method shows up as one of the most expensive in callgrind (as expected previously) and I will now spend some time and thinking in how to optimize this one further by moving heavy operations out of the repaint loop.
In the long term I hope to be able to move the compositor into an own thread (also something I have in my mind for quite some time), so that heavy operations in window management and the decoration plugin do not slow down the repainting of the compositing. This might be tricky as we can run into dangerous deadlocks (imagine compositor and window manager both blocking the X Server), so we will probably first concentrate on moving e.g. texture loading into threads – something one of our new deelopers in KWin experimented with.
Overall very nice improvements, I’m happy with, but not yet satisfied as we do not yet reach the constant 60 frames/second.

=-=-=-=-=
Powered by Blogilo

106 Replies to “Rendering at 60 Frames”

  1. Thanks for your efforts Martin ! I’m definitely one of those who experience slow framerates and I thought I was kinda alone 🙂

  2. Martin, thanks for working hard on kwin. Also, thanks for informing us on your progresses with frequent posts. They are always extremely interesting and clearly explain a lot of technical details!

  3. Sounds great. Thanks for that !
    One question remains: How to complain right? 😉 I mean, for me as user its sometimes not easy to complain in a better way than “Its not fast for me” as i can not know the details as an amateur (Like in the “Smooth Window Resizing” post, where are many people complaining, but noone can actually know how to fix it).

      1. I am not using oxygen-transparent, i enabled it for a test.

        Ok, another (simplier) testcase: just adding a maximum possible height plasma panel (default plasma and widget styles) on the top of the screen drops performance to 30fps (max) with empty screen.

            1. that is a highly unfair and, quite frankly, pathetic response. it’s the kind of thing a child would say. or an adult hiding behind a pseudonym out of safety.

              the blur effect does not behave equally well on all GPU and driver combinations. and as it is enabled by default for many configurations, it certainly IS supported, with the above caveat.

              as you can see from the follow-up response, performance is 50% better when oxygen-transparent is not used; there’s a _reason_ for this, and what Martin was referring to when he said “unsupported”.

              that the blur effect is not working well on the commenter’s specific GPU/driver combination is interesting and should be tracked down. this will require someone with that hardware and driver (i don’t believe the poster noted which driver version they were using?) to do some testing and fiddle with the OpenGL code in the blur effect.

              1. Sorry for my bad English.

                Mmm. This happened for me with all the AMD cards (integrated) that i have and all versions of open-source radeon drivers (for some time, i recheck that once in a while starting when blur was introduced).
                I can not call that a regression, it was always like that.

                Now i am talking about AMD C-50 APU. Gallium drivers.
                Plasma theme is set to default one (Air). Windeco is oxygen-appmenu. ArchLinux, kde from git (packaged, 20110813).

                About 50% improvement when disabling oxygen-transparent: that is not true.
                Enabling oxygen-transparent with blur results in huge performance decrease, yes, but the problem is not with oxygen-transparent, it just had bigger windows.
                The performance decrease depends on the amount of space that needs to be blurred.

                Every fps value I mention here is measured with still desktop (no windows moving, no input from mouse and keyboard). It is the maximum fps for that plasma/kwin/window set configuration.
                Without blur it (fps on still desktop) is always 60fps (for all mentioned settings).

                With blur:
                20fps with oxygen-transparent and some windows on the screen (that depends on window sizes!).
                30fps with oxygen and max-sized top plasma panel and default sized bottom panel.
                15fps with oxygen and max-sized top, left, and right plasma panels and default sized bottom panel.

                Just tested on another computer (R300 driver, Gallium 0.4 on ATI RV515), it gives simular results, that i will not repeat in this post.
                In the last setting it scored 13fps, for example. It has KDE SC 4.7.

                Hope that helps. If needed, I can test things on my computers. I can build kwin from git myself if needed.

                I think that a good testcase would be a simple application that produces a transparent blurred resizable window with no content.

        2. here you see exactly why we do not support oxygen-transparent. Blurring is an expensive operation. If you use the panel and size it to the complete screen in each frame the complete screen has to be blurred. This is extreme costly and a non-realistic example. Just try it: open Gimp, use an image of the size of your screen and try to blur it. Now imagine that you want to do that 60 times per second…

            1. This is the guy who thinks that it is good policy to get rid of generic, WM-provided shadows (despite the fact that literally every other WM on the planet provides them if it supports shadows at all) because of the implementation-specific deficiencies and then require that every single theme designer reimplement shadow functionality. So yeah, you probably won’t get caching. It makes sense, so don’t expect it.

              1. This is a warning: if you want to troll go somewhere else. If you want to insult people go somewhere else. If you write again a comment like this, I will delete it.

                  1. He is trolling and not telling the truth. That is quite a difference. And I won’t accept trolling and/or insulting on my private blog. If someone wants to troll or insult he should go somewhere else.

            2. It is not a still image. By activating the FPS effect you are triggering repaints. Due to the way a blur filter works in this setup the complete screen has to be updated.

          2. “open Gimp, use an image of the size of your screen and try to blur it. Now imagine that you want to do that 60 times per second”

            hmm… but Gimp is using the cpu for calculating the blur effect. I thought that a graphic card is much faster for such things like blurring.

  5. Great news!

    It seems that Kwin from some time now is getting more and more attention in performance area which is just what people wants 🙂 less bloat, more bugfixing, more polishing, more improvement of existing code and optimization I LOVE THIS! not so long ago Kwin news where mainly about new effects… which is nice but things like that you’ve written today are far more exciting! It’s great to upgrade KDE and feel the GUI to be more responsive.

    GOOD WORK PEOPLE! Cant’s wait to see more improvements! 🙂

    Martin, you are doing hell of a good job! Regards.

  6. I’m the master of complaining xD

    Thanks for this great job dude! I have no doubt you will make it to constant 60 🙂

  7. This blog post made my day! This is the kind of news I like to read.
    And reading how you dissected the problem was most entertaining.

    Also, I would be happier if somebody investigated responsiveness issues from time to time (e.g. clicking somewhere and measuring how long it takes for a menu to appear, etc). I understand that latency/responsiveness is a lot harder to measure than just fps, so I would like to see how somebody manages to analyze that.

    Keep rocking!

    1. That’s a good suggestion, sometimes after a lot of apps/windows have been opened, the menus start to appear slowly whereas their shadows appear a lot quicker and a ghost shadow is formed.
      Another bug that I face is when I come back to the desktop after playing a game the panel/kickoff is not transparent anymore.

      1. the transparency issue _may_ be a recently fixed bug where changes in kwin’s compositing (on/off) were not always caught properly and therefore the plasma-desktop components would get caught in the ‘wrong’ painting direction. this has been fixed recently, so hopefully fewer people will see such problems.

        3. @Aarin: In which KDE version this bug is fixed?

          For quite some time I have had performance problems with KDE repaints (dual-core notebook with Nvidia GPU).
          When trying different drivers I always switched off desktop effects but had slow repaints. At one point (with switched off effects and slow response) KDE showed a popup window stating “something is to slow – I switch off the desktop effects now”. I was very supprised – and then the desktop was very responsive.
          These days I have “export QT_GRAPHICSSYSTEM=raster
          ” in my ~/.profile which speeds up my KDE.

          I’m using OpenSUSE 11.3 64bit with KDE 4.7.0 and Nvidia 280.13

          1. I had horrific performance problems with my former nvidia laptop. I fear the problem lies in the drivers and only nvidia can fix this. Have you tried to see whether nouveau gives better results? It did for me but it is not yet a viable option on a laptop.

            1. I did not try the nouveau driver.
              But I did try a lot different Nvidia binary drivers. Unfortunately, that did not solve my performance problem. The export in the .profile (see my last post) is working ok for me. Because of the performance problems I used lxde for a while and now I’m back on a KDE desktop.

  8. As always, thanks for looking into this.

    I have systems with r300 gallium, proprietary nvidia & fglrx, and intel mesa, and even with the same version of kwin their behavior can sometimes vary — an effect that is superfast and supersmooth on one, is a bit slow on the other, but It definitively gets better with each release 🙂

  9. Thanks for you work Martin. I also enjoy reading this kind of blog posts with insights on the inner workings of Kwin.

    And thank you Alex for complaining. 🙂

    1. no, I used it now to investigate exactly one issue. You have to know what you want to do to use a tool like callgrind.

  11. Thanks for your work.
    Could you specify where most of time in paint method is spend? Is it spend on crunching on CPU, or rather uploading stuff to GPU, or doing operation on GPU itself, or something else like reading texture from disc?
    I ask because some of this stuff is far harder to optimise then other, and also if I can throw hardware(FE: could buying high end GPU would help to achive smoother desktop)

  13. This is totally awesome. Sure I and probably everybody would have loved to have things fast from 4.0 onward, but I guess it just takes time and better late than never.
    Things like this and Plasma Active make me really hopeful that KDE 5.0 (when it is ready) will be awesome and everything 4.0 was supposed to be.
    I hope this culture of fighting slowbloat will spread within KDE. (The talk about performance at last years Akademy destroyed my hopes for a lean and mean KDE, but maybe that was too fast.)

    There is no technical reason why KDE SC shouldn’t run in 60 frames on my EeePC 901. I wish every KDE developer had such a machine as his dev box. I guess that would do wonders 😛

    1. “Things like this and Plasma Active make me really hopeful that KDE 5.0 (when it is ready) will be awesome and everything 4.0 was supposed to be.”

      4.0 was precisely was what it was possible to be; the years of effort since are precisely what we hoped to do as well; this isn’t a shift in priorities, it’s following the game plan. some people simply expect us to be able to do 5 years of work in 1 year with the resources we have at our disposal, and that’s unrealistic. this isn’t the first time it’s been said, either 🙂

      “I wish every KDE developer had such a machine as his dev box.”

      actually, it would slow us down to the point of not being able to turn out any sort of release.

      as a _test_ box, yes. and this is where having things like the ExoPC tablets widespread is so very useful. 🙂 that is helping us spot issues and address them in a timely fashion. having targets is, indeed, helpful.

  14. Will be possible to backport those effects bugfixes (i.e. effects that do expensive checks apart of checking if they are enabled) to KDE 4.7.2? If that’s right, we have some great smoothness improvements scheduled!

    1. For dominating performance issues callgrind is just fine. Perf would not add that much new information to the picture.
      The problem I have with profilers is that I have not seen one that was able to dissect the waiting time of an application. Currently they are mostly useful for CPU bound processes.

  16. Hi,

    I’m wondering, why the real optimization by only calling the active effects will not hit as a 4.7 update?

    I mean, it is not a new feature, it is and optimization.

    Thanks,
    _____________
    Live long to KDE
    \-/

      1. So we have to wait 6+ months for what amounts to a bugfix (no, optimization is NOT ipso facto a feature)? That’s good policy there /sarcasm.

        1. It might not ne a feature from your POV but if it can cause regressions it must not go in.

          What happens if you introduce “features” or major changes into a minor version, just look at the mess with Blur effect on kubuntu natty (see here in Martin’s blog for Details)

          1. Well, this doesn’t look like a feature or a major change, so I’d say your point is moot. BTW, any change could lead to a regression, so by your logic, we ought not change anything at all in a minor release. Better testing (and automated testing) as well as better options for the user when regressions do occur would mitigate the issue considerably.

        2. First: Please save your sarcasm for people who care for it. It’s non-constructive and thereofre unhelpful. It’s not how we work within our team(s), and as such your sarcasm is not welcome here.

          What BajK says is absolutely spot-on, and people with attitudes such as yours usually create the worst of catch-22s: if we backport a complex set of changes and it regresses (something that we need to be able to do wide testing to catch, requiring often months of time), we get mauled for it; if we don’t backport them out of _respect_ for our users stability, we get mauled for it. what to do? only what we can judge as best for our users.

          we’re doing our best to responsibly maintain and grow the code base, and that means making these kinds of “to backport or not” decisons. the improvements every 6 months show our efforts. your berating of Martin does nothing.

          complaining that improvements aren’t being delivered to you _fast enough_ is a rather odd occupation, but you can help improve things by getting involved! thoroughly testing the master branch of kde-workspace on multiple pieces of hardware and driver combinations and reporting the results can only improve the pace and reliability of development efforts.

          1. Well, it just seems strange because from my point of view, this is really fixing a bug (of unusably slow desktop for some point and annoyingly not fast for others), not introducing a feature. There is no change in behavior, no real enhancement in usability (unless you *can’t* use your desktop because of KWin’s slowness). Why is this classified as a feature and not a bug? That’s really the gist of my problem. It doesn’t have anything to do with the rest of what you are talking about.

            1. There is a huge change in behavior and that’s why I cannot backport the changes. More than 40 effects have been changed and no I am not confident that I did not introduce a bug in there. This requires testing which only the master branch can provide.

            2. An “off-by-one” is a bug, a bad method call is a bug, this, on the other hand, is not a bug, it’s a design deficiency. As tempting as it may be, you can’t fix those in a maintenance release.

        3. Every code change may cause a bug. If changes are huge, the probability to make mistakes (and therefore to have new bugs) is bigger. That’s the reason why code changes are deferred to mayor releases and that’s is the good way to do things. What do you preffer, a slowly app during next 6 month or a buggy one?

        4. I think kwin effects are very much usable as is. I have an intel GPU in my laptop and for most of it effects are smooth. Getting these optimisations in 4.7 might cause regressions and frankly while i would love to get even smoother effects, i prefer to keep my smooth effects for now rather than risking bad regressions.

          1. There’s this thing called testing, which I know isn’t popular in the open source world, but does help. There’s also this thing, not generally popular in the distribution world, of allowing user-decided versions of a piece of software to be installed (or, gasp, multiple versions of the same package). If KWin 4.7.2 introduces a regression for you, then you ought to be able to easily downgrade to 4.7.1 until the regression is fixed.

        5. I help you with your problem: just forget that you ever read this blog post or that I blogged about it. If I had not blogged, you wouldn’t know there is an improvement and would not question the backport policy.

  17. Thank you Martin!!!

    This is especially important for people like me using Intel GMA drivers which are already slow on their own. Speeding up KWin will really have an effect on users like me!

  18. Thank you very much.
    Kwin performance are good in 4.7 too, but what still stops me from using opengl compositing (stuck on xrender) is the bad impact which it has on firefox scrolling.

    This won’t happen with compiz, and, to be 100% honest, is true that chromium under opengl+kwin isn’t that bad.

  19. Great news!

    Another (IMO) very important issue is compositor synchronization with OpenGL apps. When I compare KWin to Windows Aero, KWin is very poor in running GL apps in a window. When a GL app runs in a KWin window, the app produces 60 FPS and KWin itself also runs at 60 FPS (a still desktop). However, every second or so there’s a big, ugly framedrop, making the otherwise very smooth animation very uneven. In Aero, this never happens. I can play, for example, a sider-scroller video game in Aero and the scrolling will always be 100% smooth without any jerks in the motion. KWin does hick-ups every second.

    2. I suffer from the same. Every second or so, kwin drops a frame (Oh look, it rhymes 🙂 and shows the one that came before it. So every time i run my game-engine-in-development I ctrl+alt+f12. Then, after switching compositing back on, Plasma seems to not notice. Bang! I now have to kquitapp plasma-desktop, rm ~/.kde/cache-…/plasma_theme_*, and restart plasma. Hopefully the fix Aarin (Aaron, you?) mentioned comes to the kubuntu-updates ppa soon.

  20. Great Work Martin, definetly not going unnoticed. Yours and everyone else’s work has spawned myself and a friend to take programming classes and tutorials so we can help later, other than noticing problems, and can be a little more active to a very modern and beautiful desktop Again thanks

  21. not happening to me 4850×2 r600g, maybe i have enough horsepower or maybe you hitted a bug ??

    i can for example play lineage2 hi5 in 2 windows (aka main player and buffer aka dual box) at 70% of my screen size without deactivate kwin 4.7.0 while keeping firefox7 and kontact running on the background without any noticeable performance loss in either my kde apps or the frame rate of the game windows.

    note my brother laptop with an nvidia 9800gtx mobile with the blob and kwin 4.7.0 don’t slowdown either.

    so maybe your driver is at fault here or driver/kwin version combo

  22. Many thanks Martin, not just for the code improvements, but mainly for your achievement to enlarge the KWin developer community. Without all the new developers, KWin wouldn’t be where it is today.

    KWin 4.8 really is faster on my old and rusty i945 chip with OpenGL compositing enabled. And I don’t need a profiler to measure the difference; it is *obvious*.

  25. Pingback: KDE Performance Boost Ahead | PHP World

  27. Hi, can you tell us wich framerate are you reaching??

    (don’t tell me that you are in 58fps.. haha)

    1. without active effects I get between 59 and 60 fps. With an active effect it is very difficult to say as the fps effect itself influences the rendered frames and most effects do not even last one second in duration which as well makes the number fps very difficult to get.

  28. funny that I visited today the site of the “rasterman”(the guy behind enlightenment) And I found this:

    August 3:
    “””Today someone made a nice comment today that made me think. They said: “there is no hardware video accel, so it’s slow”. Then someone’s response was “slow is a relative term”. Both of which are very true. What IS fast or slow in a GUI context? Do we have any real definitions? I keep seeing people trying to make their games run faster than 60FPS in an attempt to go on about how much better it is, when reality is, their eyes won’t percieve more frames than that (we can debate center of vision vs peripheral if you want to get into details), but the point here is that in reality for most people ther *IS* something considered fast for a GUI,and then slow. This will vary from person to person, BUT there will be general ballparks.

    So what are these ballparks. What is fast? What is Slow? So I propose the following standard (median framerate):

    over 60FPS – Pointless
    60FPS – Fast
    50FPS – Good
    40FPS – Average
    30FPS – Bareable
    20FPS – Bad
    10FPS – Fail
    under 10FPS – Don’t even bother

    I know this over simplified things. What is your screen refresh rate? Really humans see about 45-50FPS in the center of vision and maybe 75FPS in peripheral vision. You can get away With 50FPS being fast, if that is your screen refresh rate. But the point of this little ditty is, that we can get a common language for what Fast is when it comes to a GUI. One should always strive to try get “60FPS” (manage to render at refresh rate – if refresh rate is 50FPS like in PAL, then aim for 50FPS). Make sure you produce an updated frame regularly every refresh (if there is something to update). “””

    1. If the refresh rate is 60 Hz, then anything different from 60 Hz will look jerky, show tearing, or otherwise annoy. If you can swap frames exactly with the vertical blank interrupt, and never miss a single frame, only then it will look smooth. Regardless if this is 50, 60, or 90 Hz.

    2. More than 60fps does make a lot of sense, because games produce very variable output.

      Depending on the game, and average of 60fps could see minimums as low as 25 and maximum’s of more than 80fps.

      By seeking more you work on the reasonable assumption that the minimum frame-rates will be higher, and high enough that they no longer intrude on the experience.

      1. If the screen is only able to render 60 frames it’s useless to render more frames, even if the game is smart.

  29. Martin, as an end user I wanted to speak for the unheard masses and thank you for investigating this and identifying a problem. I’m particularly disappointed that you seem to have had a distinct lack of praise for your hard work. It’s greatly appreciated – believe me!

  30. Thank you very, very much for the improvements. 🙂 Desktop responsiveness is what makes me look in awe at enlightenment once in a while when I’m frustrated of yet another 4.x.0 bug. Only that I return every time and use 4.7 trunk these days to get fixes more early. And hearing about this fix probably makes me switch to master much earlier than planned, again, potentially repeating the kde-e17-kde cycle once more. 😉
    Having activated the fps tool, I see that I get 60 fps at a still image. What makes me cringe every time is the latency of the application launcher. Pressing the “K” button makes fps go down to as low as 22 fps. Avoiding that sad event, I press “Alt+F2” only to watch the same again.

    1. oh btw, this happens on not so fast but very common gma4500 graphics with latest kernel-drm, mesa-git and intel-userspace-git.

  31. Thanks Martin !!!

    Is there any way we, dumb users with little time available, can support your work ?

    Oh BTW, I’m one of those who experienced a speed regression in 4.7.0 compared to 4.6.x (nvidia proprietary drivers, 9800 GTX). Most animations are actually jerky. Also, games tend to only display at half the expected framerate, expect if kwin is disabled. In fact, it’s pretty difficult to understand everything, as things sometimes get worse, for instance, when ticking “sync to vbl” in the nvidia-settings / OpenGL section.

    Well, there’s definitely something weird but you are probably aware of this. I really wished I had the coding skills to help 🙁

    Anyway : you work is ENORMOUSLY appreciated, thanks !

  32. Martin said:
    “A deeper analysis of the code showed that there is a small bug, which we will fix in 4.7.2 (too late for 4.7.1)”
    Then, who needs kde-4.7.1 release? Please omit that release for kde-4.7.0 is quit stable but kwin slowed down! (I will mask this dummy 4.7.1 release on my gentoo~unstable)

    1. sorry, but I don’t get the logic behind your statement. Of course 4.7.1 contains bug fixes not only in KWin but in many components. Why should we omit a time-based release just because one component decided to shift one bug fix into the next time-based release?

  34. I always asked to myself why windows 7 could minimize a window without any problem and kde could not (on my radeon hd 5670 video card the fps drop from 60 to about 20)… finally someone noticed it and I think that things will go to the right way. Thank you!

      1. To get smooth (fluid) desktop effects on my system with radeon card and fglrx driver, I have to turn off kwin vsync and oxygen animations. After doing that, I have (very) smooth desktop effects including minimize animation.

  35. Martin, I’m not sure if you are still reading these comments or not.

    Could you please explain what the problem with KWin and OpenGL 2.x support is under fglrx? I was thinking it was due to slow TFP performance, but I may just be making that up myself.

    I know KWin defaults to GL1.x functionality for that reason, I was just hoping to pass this info along to an AMD employee to see if they could get the ball rolling.

  36. Pingback: KDE 4.8 ???? | I, KDE

  37. Not much to say here (I am far from an expert on the matter) other than THANK YOU. Martin, your work and that of everyone else behind KDE is hugely appreciated.

  38. Pingback: Alien Pastures » Package updates in the past days

  40. Frame rate >>>>>>>>>>> eye candy

    Frame rate should be the top priority for every GUI so kudos for working on this topic.
    It’s pretty annoying that nearly no modern GUI does this right (I’m looking at you, too, Aero).

  41. That’s really awesome. Thanks for explaining what you’re doing because that’s informative for those of us who aren’t heavy programmers. Also neat to see what may be coming in 4.8! Yay!

  42. First of all, let me thank you for putting in the effort into improving kwin’s performance. I think you’re doing a really good job.

    Now, one aspect that I’ve noticed in my quest for perfectly smooth effects on my Radeon 4650m was that Oxygen itself is waaaay heavier on the resources than say QtCurve. I could get KDE SC 4.5 to be pretty darn smooth by using QtCurve instead of Oxygen. So – and I’m just guessing here – perhaps some performance bottlenecks might be found in Oxygen itself…?

    Just my two cents. Keep up the good work!

    1. This is an absolute NO NO for the 4.7 branch. We know that the change may have introduced regressions. We are confident to find them all before the release of 4.8 but that makes it an absolute NO for 4.7. As an upstream I’m telling you to not consider this for downstream!

      1. OK, makes sense, thanks for the information. Will keep this backport in a “testing versions for the brave or insane” place… If someone tries anyway against all warnings we might both be interested in the feedback, I guess.

      2. I am the user that backported it. Most of the regressions this could cause would cause compilation to break due to the things you removed from ./kwin/libkwineffects/kwineffects.h. Barring logical errors in the isActive() function or “out of tree effects”, I am not sure where the room for regressions would be.

        I can look at this in greater depth, but I am testing it on m computer and I have no problems. Would you please elaborate on what you mean?

        1. Well if you think it could just be compilation issues, you are wrong. I don’t want to go into details. I know that we already had regressions due to the change and just by backporting the patch to 4.7 you would introduce the regressions which are already fixed. And without the knowledge on how KWin works it is impossible to figure out which commits are related to that change.

          1. Were you the one that made the commits? I can look through the commit history and see what else has been changed. Alternatively, I could just read through the code to figure out how Kwin works in depth and then guess the regressions.

            Also, could it be possible that the regressions were triggered by other changes be used in combination with this? I don’t think just making it compile is enough to make it work, but I do think that it is possible to backport this in a sane way.

            1. ok, the maintainer of an application did a change and is not able to find all possible regressions. And you think that you could read the code, start to learn how the application works and find the regressions by just looking at it?

              Seriously all effects have been changed. This are something like 80-100 source files which were touched in one go and the interaction was changed in a fundamental way. The combination between effects could influence whether you see regressions or not. It is not possible to find those possible regressions.

Comments are closed.