| Summary: | Maximized transparent windows lock fps on intel graphics | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Sawyer Bergeron <sawyerbergeron> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | bugseforuns |
| Priority: | NOR | ||
| Version First Reported In: | 5.15.2 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Sawyer Bergeron
2019-03-01 23:08:32 UTC
You are demanding too much from the poor integrated gpu. Also please remember that show fps might not show accurate information especially when blur is involved. Like it says: it is not a Benchmark. Sorry, I don't know if I conveyed my experience entirely clearly. I understand intel graphics are not super powerful, but what's going on here suggests their raw compute power isn't at fault here: 1: the intel designed monitor for iGPU utilization never peaks above like 20-30% 2: the stutters match my experience with the FPS counter, I'll try other measurement software to see if they match my experience with the built in effect. 3: it is a hard drop, the window could be 2/3 of the screen minus one pixel and everything will run at 60fps with no stuttering, basically never dropping below 55 fps. The moment 2/3 of the screen plus one pixel is using transparency the FPS drops to 30 fps and never above that, nor below it. It is much more similar to a cap than something genuinely loading the GPU. From every experience I've had, if the GPU is genuinely having difficulty keeping up with a DE (GMA graphics had a bit of trouble a couple years ago) then any drop in FPS is gradual, so it will go from 60 fps down to 55, 50 and so on with increasing load. That isn't the behavior here. 4: even when redrawing isn't required for the blurred region (moving a window around in the region not covered by a window 2/3 screen size) stuttering is evident, but so long as the transparent region is less than 2/3 screen area that stuttering does not happen. If I'm mistaken I apologize for reopening this, the numbers in question just seem *very* odd if it is simply performance limitations from the iGPU. I'll try to dig into the source for the transparency effect myself to see if anything pops out at me in the meantime. It could be something within the Intel drivers themselves, who knows. I can confirm the problem here. Frame rate is 30fps while transparent and blurred konsole is open and maximized on Wayland with intel hd graphics. bug 404604 is another report related. Operating System: Arch Linux KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 Kernel Version: 4.20.13-arch1-1-ARCH OS Type: 64-bit Processors: 2 × Intel® Celeron® CPU G1820 @ 2.70GHz Memory: 7,7 GiB of RAM First of all, please don't change status of a bug report set by a developer. As Martin said, the Show FPS effect is not a reliable source to judge performance of KWin. The Blur effect in KWin is not that cheap as some people say. When you use the Show FPS effect, it can force blurring of underlying windows sixty times per seconds or more (depends on your refresh rate). |