https://bugs.kde.org/show_bug.cgi?id=440386
--- Comment #1 from Fabian Vogt <fab...@ritter-vogt.de> --- It does not happen with either "KWIN_COMPOSE=Q" or when using the framebuffer backend (which also forces QPainter). I noticed that even though the refresh rate is set to 60Hz, kwin actually renders 100fps according to the Show FPS effect. When idle, the default latency configuration substracts 0.5*vblankInterval (8ms) from nextRenderTimestamp, which then ends up at ~8ms delay between renders. As a test, I removed the substraction and ended up with ~35fps in firefox. While it undershot the FPS target quite a bit (as expected), CPU use is down to ~55% that way. According to "perf", a lot of time is spent in texture format conversion functions, because Mesa defaults to using RGBA8, but kwin's calls glTexImage2D/glTexSubImage2D with GL_BGRA. Sometimes there's also a mismatch between RGB8 and RGBA8, when the texture was created using a QImage without alpha, but updates come from a source with an alpha channel. For quick testing, I just hardcoded GL_RGBA in those places to avoid the conversion. With that, CPU% is down from ~75% to ~65%, most of the savings are probably eaten up by giving room for a higher frame rate. The next Mesa version has an optimized render path for 2d rasterization in llvmpipe, so I tried with that as well. After I confirmed that the fast path was actually used, I saw about a ~3% decrease in CPU utilization of kwin again. FWICT, the high CPU utilization is mostly from having a higher target frame rate than is actually displayed, which makes kwin_wayland fully CPU bound. -- You are receiving this mail because: You are watching all bug changes.
