In Plasma 5.8 we will see a few changes in the OpenGL compositor which are worth a blog post.
Debug information
The new KWin debug console gained a new tab for OpenGL information. This shows information comparable to what we know from glxinfo/es2_info. It shows the information gathered from the OpenGL library (version, renderer, etc.) and all the available extensions. This is intended to be useful when for whatever reason glxinfo is not working and one needs to know exactly which extensions are available.
As you can see in the screenshot: KWin also learned to add decorations around “internal” windows on Wayland. Which means the debug console can now be freely resized and moved around.
Support for llvmpipe
With Plasma 5.8 we finally allow OpenGL compositing through the llvmpipe driver. So far KWin fall back to XRender based compositing when the OpenGL driver uses software emulation. We thought that with XRender based compositing one gets better results than with software emulation. In this release we re-evaluated the situation and came to the conclusion that it doesn’t make sense to continue blocking llvmpipe driver. Due to QtQuick KWin will render parts of its user interface through llvmpipe anyway and also Plasma will render completely through llvmpipe. Thus most of the system is going through that driver. If the system is usable enough for Plasma, it will also be sufficient for KWin’s compositing.
Related to that many of the reasons to not use llvmpipe by default are going away. For example we didn’t want virtual machines to render through llvmpipe, but today also KVM can do accelerated OpenGL through virgl driver. Similar the embedded systems also provide working drivers nowadays, if we think of raspberry pi or odroid – they all can do OpenGL and we don’t have the risk of them going on llvmpipe which would result in a very bad experience.
Last but not least there is the question whether XRender or QPainter compositing is a better solution than llvmpipe. And there I’m not so sure anymore. For XRender it’s possible that the xorg modesetting driver is used in combination with glamor. In that case it would also use llvmpipe. So nothing gained by forcing to XRender.
But still it’s possible that using llvmpipe compositing will result in high CPU usage if KWin has to use it. The solution to this problem is to deactivate what we know to be expensive – all these effects which are not available on XRender because we know it to be too expensive. We don’t want blur effect on software emulation and neither wobbly windows. So we are now working on disabling the effects if we are on software emulation. For this we introduced a way to disable all animations in KWin and a lot of effects are already adjusted. This might also be a handy new features for users who don’t want any animations at all, but still want the compositor enabled.
Last but not least using llvmpipe also exposes performance problems which we normally don’t see with a fast GPU. And as a result we were already able to improve various parts of our rendering stack which will benefit all users – independently of whether llvmpipe is used or not.
Removal of GLX/EGL selection
A change which also got backported to a 5.7 bugfix release is the removal of the selection of GLX or EGL in the compositor settings. Unfortunately EGL is still not a good enough option on X11. Way too often we saw bug reports about rendering being broken and it was caused by using EGL. We decided that it doesn’t make sense to expose a config option which in most cases will result in the users systems being broken. So on X11 the default will stay GLX, while on Wayland the only option is EGL. Of course on X11 the option can still be set manually be editing the config file or by specifying the environment variable to pick EGL or to pick OpenGL ES 2.
Removal of unredirect fullscreen windows
Unredirection of fullscreen windows has been a kind of blue-headed step child in KWin’s compositing infrastructure for a long time. It’s a feature not loved by the developers, not properly integrated, but you have to support it. For those not knowing the feature: it excludes an area from compositing and let’s the fullscreen window be rendered the normal way in X11 (unredirect). The idea is that you get slightly better performance if you bypass the compositor.
The functionality was never fully integrated into the compositor. It was way too easy to break out of the condition (e.g. a tooltip), but at the same time effects which should break it, had no way to do it (e.g. Present Windows should either not activate or end it). The weirdest oddity of the feature is that we had to hard disable it for all Intel drivers due to crashes. We don’t know whether this is still the case but after having had such a bad experience with it in the past, we decided to never turn it on again. Which means it’s a feature not even supported by all devices.
We developers did not spent much time on the feature as we think it doesn’t make much sense as KWin has a better infrastructure in place: blocking compositing. Applications are allowed to specify that compositing should be blocked. This results in KWin shutting down the compositor, freeing all resource related to it (e.g. destroying the OpenGL context), so all power to the running game. As the compositor is shutting down, you don’t have weird interactions like tooltips jumping out or effects not working properly.
There is a standardized way for applications to request this and we see that many games and applications (e.g. Kodi) make use of it. This is the preferred way in our opinion. Given that this mode is fully supported, we decided to remove unredirect fullscreen windows from KWin’s compositor. This streamlines our implementation and gives us one feature to concentrate on and make sure that it works exactly as our users need it. On Wayland the architecture looks different: there is no such thing like unredirect fullscreen, but we can ideally just pass the buffer to the DRM device. The idea is that we do the best optimized way whenever possible.
Support for render devices
Our virtual rendering platform in KWin/Wayland gained a new feature. Like the normal DRM device it now uses udev to find all possible devices and will default to a render device (e.g. /dev/dri/renderD128) if present. If not present it will look for a card device created through the vgem driver. This is a change intended mostly for the use on build.kde.org so that we can properly test OpenGL compositing, but is also a handy feature for running KWin in the cloud on systems with “real” GPUs. If no GPU is present one can easily make KWin pick the virtual device.
Support for restarting the compositor on Wayland
Initially KWin did not support restarting the compositor or even switching the backend on Wayland. But of course we need to support that as well. The OpenGL driver might do a graphics reset after which our infrastructure wants to reinit the complete setup. Thus KWin needed to learn how to restart the OpenGL compositor on Wayland, which will be fully supported in Plasma 5.8.
> There is a standardized way for applications to request [blocking compositing] and we see that many games and applications (e.g. Kodi) make use of it.
Even those closed source games on steam? Otherwise it’s a pretty useless feature imho, since you hardly need this performance benefit for most open source games anyway.
Well this is KWin, if applications are broken you can fix them 🙂 E.g there is the game mode script and of course window specific settings also support this feature. So if the proprietary game does not support it: just create a rule.
Unfortunately these rules cause a number of bugs, e.g. https://bugs.kde.org/show_bug.cgi?id=357116
These bugs need to be fixed. We don’t do our software design decisions based on bugs we currently have. We expect those bugs to be fixed till Plasma 5.8, though we need help with them (read: I’m not able to reproduce them).
Unlike KWin 4.x, I had very good experiences with XRender on KWin 5.x. So good, in fact, that I just wanted to try it once and soon forgot that I was using it and kept using it for months without noticing.
I didn’t do scientific FPS comparisons in games but it should result in similar FPS gains than blocked compositing.
Dota 2 and Civilization V does that (the games I play, can’t tell about others), even with Steam Overlay. In fact, kwin is the only windows manager which didn’t gave me headaches.
Can confirm that most most games on steam makes use of this infrastructure to disable compo when they start and reactivate it when they close.
SOURCE: there is a bug that makes all your screen flicker with black frames when the compositor is suspended and than re enabled in this way… Easy solution is to manually disable it before launching the game with CTRL-ALT-F12.
Past posts of yours made it sound that QPainter is better than XRender for software compositing. I wonder why the drop-down menu does not offer QPainter.
QPainter is only available on Wayland.
What’s the difference between “unredirection” and “blocking by request” ? I.e. if you’re going to only block by request, that wouldn’t solve broken drivers; unless the whole idea is that not much apps would probably use the feature, artificially reducing number of bugreports.
The difference is that blocking compositing means the compositor gets completely disabled. Not just the unredirection being in place. It’s the same as if you use an uncomposited window manager again. We know that this is not causing problems with drivers, because it’s something which happens all the time: when KWin shuts down the compositor gets first terminated, then the rest is terminated. Thus there is always a short time where we are in exactly the same condition as with blocking compositing. Or similar if a user presses Alt+Shift+F12 twice, or changes configuration settings related to compositing.
Erm of course not. I hope that nobody gets such an idea.
Ah, nice. So, “unredirection” is an absolutely different thing.
But then, why not to disable compositioning for every full-screen window; given it doesn’t cause as much problems as “unredirection”, that seem to be a great replacement.
You don’t want to disable compositing for every fullscreen window. That would for example cause severe issues on multi-screen systems: why disable compositing just because on the other screen there’s a fullscreen window?
You want to disable compositing when it’s required. E.g. when playing a game, when doing something which really needs the GPU. Or although a CAD application – which is not necessarily running as fullscreen. It’s just nothing which should be bound to the fullscreen state.
>Removal of unredirect fullscreen windows
Goodbye, kwin, moving back to compiz 0.8
You didn’t read my blog post, right? We have something which compiz never supported: blocking compositing.
But I don’t want ‘blocking compositing’, it’s just awful. I wan compositing always on, regardless of what applications think of it.
If you want use-case: multiple screens. I don’t want all compositing/effects gone on all of my screens just because I have some fullscreen application running. No way!
Sure. If you don’t want that: create a window specific rule to disallow it. Also we are considering to add a dedicated config option to allow whether applications can block compositing.
Then maybe someday you (I mean all of KDE devs) consider adding a config option to make plasmashell crashes gone? Or an option to squeeze these horrible Qt themes to make them fit 13″ laptop screens again? Or a big desktop button ‘KILL Akonadi’ because it won’t start properly 1/5 times?
Seriously, I’ve read so many posts of how much better designed software KF/Plasma5 is, compared to KDE4, but it’s just not working correctly when you try using it. That’s really disappointing.
I’m sorry that our software doesn’t satisfy your needs. As there are multiple Desktop Environments available I suggest to give them a try. Maybe you are better served there.
Don’t be sorry, I’m just another jerk you met on the internets.
And for now (kwin 4.7), after compositing was restored from ‘blocked’ state, the screen would flicker when some new windows appear (like, on spectacle start) and some minor desktop corruption occurs (black rectangles). It doesn’t matter if compositing was blocked by a rule, or you’ve just changed something in System settings, which cause compositing restart. I’m almost sure I’ve seen a bug on bugzilla, but I cannot find it now. Is this fixed?
That sounds like https://bugs.kde.org/show_bug.cgi?id=361154 – unfortunately I’m not able to reproduce the issue which makes it really difficult to investigate. If you have any further information on how to trigger it: please tell! That’s currently one of our top priority bugs, but without a way to reproduce there is just nothing I can do about it.
I can’t tell anything specific, but my desktop corruptions do not look anything like on screenshots provides with that bug. The desktop corruption is black series of black rectangles outside of active window. They’re usually located in upper left corner of the screen, and disappear if that section of the screen is redrawed. I tried to make a screenshot, but failed, it seems that entire screen gets redrawed just before the shot. Maybe I need other tools.
What information you want me to provide? And where should I put it? I can’t send you my entire laptop, but I could think of giving you a remote access to it if that would help.
I can always reproduce it by starting the Shadow Warrior game, the latest one, on steam.
Make sure it’s running in full screen on one screen, and whilst the game is running, have another screen showing a youtube video in a chrome browser window.
Once you exit the game, there will be corruption on the window borders.
Please add that option with all haste.
I absolutely hate that I’ve had to make a global window rule to override the option simply to preserve my sanity, and keep the desktop in a usable state while games were running.
Just look at the plasma5 shell; the last time I allowed SDL2 to inhibit compositing, plasma was stuck in complete visual stasis until the game exited and compositing was restored.
It just makes for a awful user experience when programs can just disable the compositor and cause such problems.
So you don’t only get irate comments about unredirect fullscreen…
About “Support for render devices” – is that fully functioning for desktop use? For wayland? I ask because on Tegra K1 chromebooks there is basically one “GPU” that is connected to the display and as far as I know it can only do very basic 2D. And then there is the beefier nvidia GPU that is not connected to the display at all. The problem is: The modesetting ddx on that hardware doesn’t have dri3 yet and xf86-video-nouveau apparently has some trouble starting up, so DRI_PRIME can not really be used.
Now there are hacked solutions.
1. For X: https://github.com/Gnurou/xserver/commits/gk20a. It’s basically hardcoded to open /dev/dri/renderD128 and do graphics acceleration through that. Works surprisingly well. Plasma and other KDE programs have a tendency to lock the whole thing up, but that might be a nouveau bug, not sure.
2. For weston: https://github.com/Gnurou/weston/commits/gk20a. That’s my real question. Weston with these patches works fine, but kwin and mutter etc. still use llvmpipe because they’d need to do patches like these too. Is this Support for render devices a working solution for that situation on wayland?
Unfortunately not. Render device support is only available in the virtual rendering platform. That is when no output is supposed to be rendered at all. KWin does not support DRI_PRIME at all yet. So yes similar patches are probably needed.
Hi !
A bit sad about the unredirection of fullscreen… A lot of applications will never add the standardized way you are speaking about 🙁 So watching a video in fullscreen without glittering won’t be possible anymore with a 6 or 7 years old PC.
Saying the obvious: you don’t need to update to the latest version with your 7 years old system. You can continue to use older software which is better suited for such hardware. Especially considering that the web requires all resources it can get.
Unless, you have your new 4k screen laptop and you want watch youtube.
In that case you have to buy another older PC with smaller resolution to comfortable watch stupid cats on the internet…
from 5.5 this DE is so f..ing unstable ;/
but gnome have so ridiculous UX…
I hoped that this project will be better in new version, but 5.6 was worse, and 5.7 also anything better… now you removing options that allowed me to watch youtube…
I’m sorry that our software doesn’t meet your expectations. As there are multiple available desktop environments I hope you find one which will suit your needs.
And this is why KDE loosing community,
because of those nicely said “f..k you”‘s
And you can expect anything in new release, no public roadmap, just random blog posts where you can read what was already changed and when it is already too late to report objections.
This isn’t how open source project should be working…
I’ve not had any problems with stability for a long time, if you are reading these posts then you must be using bleeding edge stuff (or close to it) so you need to expect to have to deal with issues. If you don’t want to deal with issues then you’ll need to roll back to a stable release. Hopefully you’ve logged all your issues on bugzilla to help open source work as you expect it to…
Can we get one thing clear: we don’t break stuff deliberately. Do you think we go “ah let’s break gaming experience today”? Do you think we did not evaluate the situation properly and only did this change if we are absolutely sure that it’s the right thing to do?
Do you think I did not know how the gamers would react if I announce the change? Nevertheless I did it. I expected a shit storm, nothing less.
Yes, I think you didn’t evaluated the situation properly, because you don’t have any telemetry or other usage statistics, therefore you cannot say that this is rarely used feature.
None of our developers isn’t using that, so we remove it because this shouldn’t be implemented like that in the first place.
Ok there is an api for applications to do that, but there isn’t any announcement in advance for other developers to have any change to adapt that in their application.
Instead of that lets just remove some features and users can live with for few months before it became supported by other applications.
>Do you think I did not know how the gamers would react if I announce the change? Nevertheless I did it. I expected a shit storm, nothing less.
It sounds just irresponsible. “I know it will be breaking change, so lets introduce it without notice”
But we have the metric. We saw the bug reports and complaints in support channel when we introduces the blocks compositing hint gets honored.
Also we have another kind of metrics. I do know which areas related to unredirection of fullscreen windows have been broken for years. And if you don’t get bug reports for those, well it says something. Also we ask for support information in every single bug report and that also tells us a lot. In addition we have the support information which we ask for in every bug. From that we get how many users have it set.
I dare to disagree. While you don’t necessarily need the latest version of a desktop environment, you DO need the latest versions of the base GNU system components, network services, web browser and whatever applications you use to open files downloaded from the Internet. Otherwise your system’s security is swiss cheese and you can look forward to it becoming a botnet zombie and having all your bitcoins stolen.
Now, please tell me which distribution provides all the newest apps and system components, while keeping, say, KDE4 desktop in the repositories?
There is none. You either get everything updated, or keep everything Shellshocked and Heartbleeding.
When you said “but we can ideally just pass the buffer to the DRM device” does that mean you could, for one screen, pass directly the buffer of an application to that screen? Or it would not work for a multi screen desktop and will go through normal compositing. Thanks.
Yes the idea is that we pass the buffer directly from an application to that screen and that fully multi screen aware.
> Removal of unredirect fullscreen windows
Am i reading this correctly? If one application does the “blocking compositing” request then all compositing is blocked?
So in a dual screen setup just having one application in fullscreen stops all compositing on both screens? Basically throwing the other monitor back to software rendering.
Please tell me i’m not reading this correctly.
Only if the full screen application does the request.
Hi Martin,
I kinda fail to see how the standardized way is any better then “unredirect fullscreen”. Specially for multi screen users (i’m one of them) will most certainly see a big benefit in unredirecting fullscreen applications.
From a maintenance point of view (ans as a developer) i perfectly understand why you did this.
From a user point of view i’d like to ask you to reconsider this change. It might be on the level of the legacy system tray. It was removed for perfectly fine technical reasons, but turned out to be a quite a bad user experience. This change can have the same effect only with a smaller userbase (since there simply are less dual screen users then single screen ones).
Also, i hate it when my screen moves to compositing -> software and then compositing again. I’ve had that in the past due to driver bugs. Now it’s going to be a “feature” when a (fullscreen) app sets some flag.
I’m very sure that this is not an issue on multi-screen in practice. Unlike unredirect-fullscreen where I’m aware of many bugs in multi-screen setups and none of them got reported. It says a lot.
Hi Martin,
Correct me if I’m wrong, but isn’t the “block by request” the same as pressing alt-shift-f12 ?
So in a multiscreen scenario will KWin ignore the request or fulfill it ? I mean in one case you lose performance but other screens stay unaffected while in the other case other screens won’t be composited anymore. Both cases have drawbacks in my opinion.
Unredirect sure wasn’t perfect but was an okay compromise for the drivers that didn’t suck with it (like proprietary NVIDIA ones). I can understand if you want to remove this for code maintainability/refactoring reasons, but in the other case, if it’s just about avoiding bug reports due to bad drivers/hardware maybe it would be wiser to flag it as unsupported but still leave it possible to be enabled via environment variable/config file ?
Again thanks so much for the effort you have put in KWin and for your very insightful blog posts.
KWin honors the request also in multi screen. Though I don’t think that is a realistic scenario.
What isn’t a realistic scenario? I have three monitors, and often play a game on a single monitor with the other two still on, sometimes with a full screen video on one of the others.
How will that be handled? The game will either be fully composited, or if it requests, the compositor will completely shut down for all screens?
Kwin has probably been the most stable and reliable pieces of kde 4/5 since they were released. Things just worked nearly all of the time (the early days of kde 4 had issues, but let us never speak of them again >:( ). I wish there was some way to get kwin to notice a full screen window on a screen, and disable compositing on that screen alone.
Oh hey, just remembered one thing that’s been bugging me. Sometimes menus from plasma show up on the wrong screen. Is that a kwin issue or plasma? Plasma’s multi display support is super buggy, so it very well could be plasma’s fault. That said, plasma in general is pretty buggy. Right now plasma is OOMing itself on a machine with 32GB ram after only a day. Then there’s random CPU issues, and the aforementioned multi display issues 🙁 I know you don’t have much to do with plasma, i just wanted to vent 😉
> Due to QtQuick KWin will render parts of its user interface through llvmpipe anyway and also Plasma will render completely through llvmpipe. Thus most of the system is going through that driver.
This may change soon though: https://blog.qt.io/blog/2016/08/15/the-qt-quick-graphics-stack-in-qt-5-8/
Hi, Martin! Do you have a plans to add support Vulkan render backend to Kwin?
No
But why? In OS X El Capitan, Aqua has rendering through the Metal API, and shows better performance then OpenGL. In my opinion is a good idea to add Vulkan backend to KWin, along side with OpenGL and Xrender.
Because I currently don’t have any plans to support Vulkan. I’m busy with Wayland, I don’t have time for yet another compositor. Thus currently no plans for Vulkan.
Ok, i got it. Thanks for your hard work!
Also, in order to benefit from Vulkan, rendering should be rewritten in more parallelized fashion. And that means a lot of changes to the compositor architecture (KWin doesn’t have parallelized rendering at present). It’s not a simple “switch to new API” update.
I tried to make a rule for individual window (a game), but after the game is opened, the whole desktop loses compositing, even when that window is minimized. So it’s not a proper substitute for “disable compositing for fullscreen windows”. Or I’m doing something wrong? How can it be disabled only when that window is not minimized?
For that you would need a KWin script which disables the blocking when minimizing the window.
So, basically your position is: “We will do everything right in software-engineering aspect, and if users want nice user-experience, just like it was in previous versions of our software, let them make their own user-scripts. We don’t care if that would be non-trivial task for average user.”
Don’t you see why this suc^W unsuitable?
If you think that’s our opinion: better go away, you annoy me.
they annoy everyone
why are so many “anonymous” posters so scared to get a nick we can attribute to them?
Is it possible to extend window rules based on certain conditions? I.e. it would be way more flexible if the rule said:
-> apply the rule when “window is not minimized” and X or Z etc.
Would you consider this as an enhancement to KWin window rules setting? It would make it more user friendly than writing scripts for that purpose (even though it would still be pretty advanced feature).
I’d say it could be useful in general, besides just solving this particular issue.
No the rules system is static. For dynamic “rules” we have scripting.
Alright, I’ll take a look at scripting. Still, while I don’t agree with the tone of the commenter above, I wouldn’t dispute the point that in this case certain functionality was removed, and replacing it would be beyond the capabilities of common user (i.e. non programmer).
I can understand that the whole feature is transitory if you consider Wayland to be the ultimate goal (where this is handled differently altogether), but at the same time Wayland support isn’t fully ready yet. I.e. it’s “in development”. Do you think it’s a good practice to remove actively used features, before usable replacement is ready? I.e. sure, there are quirks with this but this feature is used at present by those who are still on X11.
A feature that is broken on the latest you vendor can hardly be considered as used presently
You mean it’s broken on Intel GPUs? I suppose, most gaming happens on discreet (AMD / Nvidia) cards anyway, where this feature is actively used. I know for sure that I use it for gaming, and I’ve heard many others using it too for the same purpose.
Interestingly, in some games like those based on Unity, I on the contrary, keep compositing on even in fullscreen. Because Unity is horrible with tearing, and its internal vsync settings have don’t help. KWin composting does a good job of fixing tearing in such games. But Unity games tend to be not very demanding / high performance ones, so it doesn’t matter much there.
Thanks for your work and for your blogs, always very interesting to read.
Wayland is the future. If removing badly supported features from X11 reduce the maintenance work and leave you more time to work on Wayland, then go ahead regardless of what some people say.
Regarding passing directly the buffer of fullscreen windows to the DRM device on Wayland, is there a standardised way for wayland clients to do that ? What would happen in case of a notification for instance ?
Our idea is to evaluate in every frame whether we can directly pass the buffer to DRM device or need to go through rendering. E.g. if there is a notification we see that we need to go through the compositing pipeline. If we notice that we can pass the buffer directly, we will do so. The clients are not involved in that at all. If we can do it, we will do it.
As I understand it, the compositing pipeline takes the application-provided frame as a texture and draws a new frame from scratch, effectively blitting fullscreen app’s frame from one buffer to another. This adds latency and eats a significant amount of memory bandwidth, especially on low-power SoCs and APUs where bandwidth is usually scarce and a significant bottleneck for 3D performance. For the end user it means animation stuttering whenever a notification or whatever forces the compositing path.
What if a special compositing mode was implemented in KWin for fullscreen apps, where the app-provided fullscreen frame would be used not as a source but as a destination onto which the notifications are blended? Say we make a compute shader that imports the FB as a R/W image buffer and manually blends in the notification windows to affected pixels, bypassing the normal 3D rendering pipeline. This way, only the pixels covered by the notifications (which are normally at most a few percent of screen area) would need to be touched; the remaining screen area would not be uselessly read and written, saving heaps of memory bandwidth and reducing latency. If a large enough overlay window appeared (maybe Yakuake?) or an effect was triggered that requires the 3D pipeline, then we could fall back to the traditional compositing path.
I believe modern game consoles display notifications in a similar way. There is no stutter when the PlayStation 4’s OS displays a notification over a running game, and I see no reason why Linux desktop should be worse.
What you describe is the buffer age extension which KWin uses if available.
Lets hope this will change plasmas bad gaming performance compared to all other desktops (cinnamon excluded, it has the same laggy effect on games)
How do I disable this ‘composite blocking’ globally? Maybe some kwinrc option? I don’t want programs being able to turn effects off on their own accord.
You can create a window rule to disallow blocking of compositing. For Plasma 5.8 I plan to add a config option.
Thank you. Is it possible to add a window rule that would match all windows, or I should add rules for each program?
Yes you can create a global rule to match all windows
Martin, I did some testing (Plasma 5.7) with the different permutations re demanding games. This is what I found:
1) Compositing using OpenGL3.1 is definitely very light, and has minimal effect on the game performance. (Game is Victor Vran, GPU is radeon 7770M using radeonsi)
2) If tearing prevention is set to anything but “None”, performance tanks to about 1/3 of before. Everything is sluggish and slow even when game is minimised. I had a look at the GPU usage, and it dropped down to about 40% usage in my test case. This drop is surprisingly large.
So, could you for Plasma 5.8 please investigate adding a different behaviour to tearing prevention?
e.g. an option to only disable vsync if the fame rate goes below a threshold? e.g. it drops under refresh-rate of monitor (it would be fine if only adjusted this every few seconds)
And the option where you disable blocking of compisiting, to disable vsync instead?
Because I prefer the smoothness of regular tearing prevention, but it severely impacts the performance of games.
Do I make sense here?
No, I don’t think the majority of users would appreciate tearing. Here we should not forget that gaming is just one use case. If you watch a video you don’t want tearing – ever! From a compositor perspective those two usages look very similar.
What’s important is that tearing prevention works well, e.g. that the driver supports buffer age and that KWin can make use of it. I do not know whether radeonsi driver supports buffer age.
Exactly, I want to leave vsync on (especially for videos), except if I play games that struggle on my system (which is getting more common).
If I have some way of disabling vsync only when a certain app is running, possibly through window rules, that would make it much better for me?
Unfortunately I have no idea what buffer age could buy us?
Maybe just use the window specific rule to block compositing? Then KWin’s compositing is removed from the equation and vsync in KWin doesn’t matter as not used.
But no, that won’t be added to the rules system. In general the compositing rendering is not linked to the rules system at all.
I tested blocking compositing with a window rule on my gentoo plasma 5.7.3 installation and it did nothing that I could discern.
Another question, do you know if an OpenGL app/window requests vsync to be force disabled?
Wait what? If I have multiple monitors, kwin will then suspend compositing on both if an application goes fullscreen on one, even though those two monitors can trigger a new vertical blank at different points in time and otherwise also are pretty independent of each other?
Why? Who would want that? Instead of doing the unredirect fullscreen stuff or the blocking compositing stuff, can’t you provide a way where you’ll automatically block compositing on only the monitor an application goes fullscreen on, if the user or the application requests this?
When an application wants to have control of vsync (hence why they block compositing), what it usually means is “I want to have control of vsync on the monitor I’m running on”.
Very sad to see the removal of unredirection of fullscreen windows. To me, this was the most essential feature of KDE, I have a hard time continuing to use KDE without it. The reason is that I have never seen smooth, stutter-free video playback on X.org when compositing is enabled (on AMD and Intel cards). The inherent X.org/compositor stuttering is kind of semi-acceptable for regular windows, but in fullscreen, playback has to be perfect, choppy video is unacceptable. And for me, the only way to get stutter-free fullscreen playback on X.org, or namely Plasma/KWin, was either to disable compositing, or use the unredirection of fullscreen windows. I vastly prefer the latter, as it’s so much more user-friendly, plus disabling/blocking compositing can bring undesired bugs or effects, too (like tearing or flickering).
So while I respect the decision, I would certainly prefer it the option stayed there at least as an unsupported option (even if it was hidden in a config file somewhere), as I cannot see a comparably good alternative.
You know that it never worked on those Intel cards you have there?
Some days ago (Oct/2016) I upgraded my Plasma to 5.8.x version. I am running Gentoo/Linux and I really can’t find a way to properly launch wayland session. I use xinit to start Plasma from tty, but startplasmacompositor doesn’t work for me. I don’t use sddm to start wayland, because that doesn’t work either.
The only way to fire up a (windowed) wayland session is within another X-session and then enter in a console:
export $(dbus-launch) ; kwin_wayland –xwayland plasmashell
I use OpenRC if that matters.
Yes you need the logind dbus interface to launch Wayland
Thank you very much! I think I should bug report about it though – I can’t find something relative to logind in Gentoo.
I decided to install systemd (GNOME and other reasons) and SDDM once again failes to login me in plasma wayland. When I try from a tty to run either “startplasmacompositor” or “export KWIN_COMPOSE=Q ; export $(dbus-launch) ; kwin_wayland –xwayland plasmashell” I get exactly the same error:
No backend specified though command line, trying auto resolution
kwin_xkbcommon :XKB: /usr/share/X11/locale/iso8859-7/Compose:85:29 string literal is not a valid UTF-8 string
*
*
*
kwin_xkbcommon : too many errors
Once again I can start a nested wayland session from inside kwin_x11. What am I missing?
Sorry I don’t know and honestly the comment section of my blog post is not the right place to investigate.
Great! Tell me where I should write
Maybe you should file a bug report with Gentoo and whatever they mess up with packaging.
Under openSUSE I can just install the Plasma Waylang session package, select it from SDDM and it just works but openSUSE. Obviously with their insistence to use OpenRC by default, they need to take extra care to get dependencies and permissions right.
Gentoo caused problems in the past as well with their weird eudev thing that messed up Plasma’s device notifier.
I am already up to it 😉
https://bugs.gentoo.org/show_bug.cgi?id=597774