| Summary: | _KDE_NET_WM_BLOCK_COMPOSITING should be advertised in _NET_SUPPORTED property on a root window | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mad Fish <MadFishTheOne> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Mad Fish
2011-08-09 14:44:45 UTC
If you're wondering, why it's important, OpenGL program may want to use VSync only when WM is not compositing OR if compositing was succesfully suspended. That's why program needs to know, if suspending is supported. "static bool KWindowSystem::compositingActive()" - it's just a wrapper for an X11 check and shows whether the desktop is actually now composited. If _KDE_NET_WM_BLOCK_COMPOSITING is supported, that only means the WM will react on it when the window sets it, but it's by far not the only way to impact the compositing state - esp. for non compositing WMs ;-) PLease have a look on the function to ensure you really want and need to check this property. Could be announced anyway, but i don't think it's what you actually want. Ok, the detailed situation: I'm developing a game, it uses OpenGL for rendering. I want to use VSync to avoid tearing (GLX_EXT_swap_control), but using VSync with compositing on X11 doesn't actually prevent tearing from happening (limitations of X11), but slows down the app significantly (haven't measured yet, but looks like 2x slowdown), which is completely unacceptable. This means that I want to use VSync in my app ONLY when there is no compositing. I also need to support all popular WMs, not only KWin. Unfortunately, as it seems, there is no way to watch for X11 selection owner changes (interesting selection is _NET_WM_CM_S0, which is what compositor uses). So I cannot use it properly to determine when compositing stopped. So, what would you recommend? (In reply to comment #3) > slows down the app significantly (haven't measured yet, but looks like 2x slowdown), if you sync once, you'll get screen fps. if you sync twice, you'll get 1/2 fps of the screen. if you sync thrice, ... ;-) > Unfortunately, as it seems, there is no way to watch for X11 selection owner > changes api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKSelectionWatcher.html There's a bug about plasma not changing the theme on selection events, but i errr... do receive them here. No idea what's broken (for those users and) in plasma *shrug* You don't have to link kdeui but could spy on the code about the events X fires. > So, what would you recommend? In addition to the above (listening to the X11 events) you could just check for the selectionowner every few minutes and adjust the vsync setting (ie. the poll approach) Indeed, there is a way. Thanks for a tip! There is now standardized API for this. |