Version: 4.8.0 (using KDE 4.8.0) OS: Linux As suggested here: https://bugs.kde.org/show_bug.cgi?id=271792 Here is a new bug report; kwin seems faster, but still it scrolls webpages slower than compiz when opengl compositing is enbabled. To make the effect more evident, activate vsync into kwin effects. Reproducible: Didn't try Steps to Reproduce: Activate opengl effects and vsync in kwin Go to this page and start test http://sliste.sl.funpic.de/bmark/ Do the same with compiz compositor Note that it reports a lower value ....this is the numeric way, but if you go to an heavy website and scroll page, you'll see that kwin is jerky Actual Results: With an nvidia 9500gt using proprietay drivers i tried openbox without compositing, kwin in opengl mode and compiz. i get this results: #nvidia-settings -a InitialPixmapPlacement=x x=0: ob:10792 compiz:12579 (+14%) kwin:15500 (+30%) x=1: ob:2405 compiz:2789 (+13%) kwin:3636 (+33%) x=2: ob:2192 compiz:2416 (+9% ) kwin:3460 (+36%) x=3: ob:2428 compiz:2705 (+10%) kwin:3527 (+31%) x=4: ob:12081 compiz:12915 (+6% ) kwin:15696 (+23%) In brakets the overhead versus openbox. I toke the best result out of three tries, but Kwin loses sistematically, and in the fastest test (x=2) it has the largest gap with a result 27% slower. Expected Results: I don't expect a composite environment to be on par with an uncomposited one, but at least kwin should reach compiz performance.
Maybe this could help to track down the issue, seems that if firefox is the only open window on the screen things get better and kwin tends to compiz performance and sometimes it is even better. Still, even with just one window, my eyes see firefox scrolling smoothly under compiz.
I didn't test to vary the InitialPixmapPlacement variable, but I'm also using nvidia blob and it seems that the kwin opengl compositing values are still within the 10% range for me (compared to openbox or kwin without compositing). The per measurement uncertainty should be around 5%. The detail that it depends on the height of the window stack raises two questions: do you use oxygen-transparent and what does the cpu usage look like when performing the benchmark?
I'm using a simple qtcurve theme, no transparency. cpu seems to jump to 75% per core, one by X, other by firefox.
[ ] mentioned firefox version [ ] mentioned firefox settings (eg. "smooth scroll") [ ] mentioned compiz effects and settings [ ] mentioned kwin effects and settings [ ] specified kwin backend (GL / GLES) [ ] specified kwin graphicssystem [ ] provided details on the window stacking (since it seems it's important) eg. whether the FF window is partially occluded [ ] provided sysprof log [ ] bisected effect plugins Does phoronix now provide trainings on "benchmarking" :-P -- So much for being mean (Sorry, I need that from time to time :-) Now here's the important part: ----------------------------------- After switching between compiz & kwin, make sure the compiz decorator process (emerald, kde4-decorator?) isn't running anymore, because that *considerably and reproducably* slows down "kwin" performance (at least here, by factor 1.5) FTR: I cannot measure notable differences between kwin/GL and compiz (while kwin tends to be slight ahead...) - kwin/XRender -quite expectably- beats the sh** out of compiz in this little test and is close to the uncomposited case ;-)
Created attachment 68678 [details] glxinfo
Created attachment 68679 [details] Xorg.0.log
I admit i read phoronix, but i posted that benchmark results just to have something "solid" to work on... numbers :) By using eyes, you can go to http://news.google.it, wait for the page to fully load, then keep down arrow key pushed. Do that under compiz, do the same with kwin. On my setup, kwin is clearly jerky, when compiz jumps just from time to time. You were right about emerald in the sense that his process didn't terminate, but i didn't noticed any real gain by killing it. Firefox is at version 10.0 and yes, it has smoothscroll active. Compiz setup is at 60fps with vsync active kwin has vsync enabled too. forced vsync is disabled under nvidia-settings kwin backend is opengl and graphicssystem is raster (default under qt 4.8) firefox window is fully visible and no windows are under/over it ...but i found a workaround: in /home/root/.kde4/share/config/kwinrc, if i set: RefreshRate=120 and MaxFPS=120 it is much, much smoother, and benchmark results are on par with compiz. without tweaking kwinrc, if i enable show fps kwin effect, i get smooth scrolling, i wonder why. Now tell me what should i do, now the bug could be resolved as invalid, but if setting that values smooth out things, that just means to me that maybe something into kwin core is not quite right, i could be wrong.
Is it off to an external screen from a notebook?
Nope, but ehm, i forgot to say i use a twinview setup with two identical monitors, one plugged via vga, the other via DVI. but refresh rates are perfectly the same, 60.02hz on both (as reported by nvidia-settings). Now i tried to disable one of two heads, it is much, much better. tweaking kwinrc still does something but not that much anymore. So the issue seems to be related to twinview/xinerama... whatever.
vsync on twinview isn't a too great idea anyway, but it could be that the refreshrate is misdetected. run "kdebugdialog", enable kwin(1212), run "kwin --replace &" from konsole and watch the output about the detected refreshrate (if there's too much output: konsole has a search feature ;-) for a pending patch on vsync check here, also read comments about refreshrate detection (currently uses nvidia-settings...) https://git.reviewboard.kde.org/r/103058/
Refreshrate is correctly detected by kwin, it says 60hz and as (now for me) expected, disabling vsync leads to smooth scrolling as well as... tearing :) Next week i'll try to apply that patch, thanks!
Applied the patch, it seems it works good, thank you very much. Speaking of vsync, i've to add that (with and without patch), when a lot of windows are on the screen, i can observe tearing on wobbly windows effect. Curiously, activating show fps effect makes the tearing goes away (but it makes the entire desktop 'choppy')
Oh, with the patch zoom plugin flickers likes hell when zooming/panning the view
feel free to try an update: https://git.reviewboard.kde.org/r/103058/
I tried and it is glitch free, but scrolling is choppy again (maxfps and refreshrate override fixed it)
Please ignore the very previous comment, i was wrong. Here are some numbers and impressions: Desktop with windows on both monitors:
Please ignore the very previous comment, i was wrong. Here are some numbers and impressions: Desktop with 5/6 windows on both monitors no maxfps/refreshrate override: plain kwin: 2841 3044 3018 2997 choppy scrolling patched kwin: 3023 2981 3106 2902 choppy scrolling maxfps/refreshrate override to 120: plain kwin: 3069 3102 3133 3352 smooth scrolling patched kwin: 3136 3123 3183 3154 smooth scrolling Desktop with all windows minimized on both monitore: no maxfps/refreshrate override: plain kwin: 2331 2287 2316 smooth scrolling patched kwin: 2210 2333 2201 smooth scrolling maxfps/refreshrate override to 120: plain kwin: 2238 2228 2304 smooth scrolling patched kwin: 2242 2431 2396 smooth scrolling ...I know those numbers aren't consistent at all with my previous measurements/impressions. What is changed meanwhile are the nvidia drivers, now at 295.20, before at 290.10 Seems that with 295.20 the patch isn't needed, maybe they touched the twinview code? The problem now seems lot of windows on the screen, even if firefox is the topmost one.
luckily one isn't related to the other - but i scratched my brain on "raising MaxFPS helps" what should not happen (makes no sense) and lead me somewhere - i think ;-) -> new try on https://git.reviewboard.kde.org/r/103058/ Much fun testing.
FYI: i've updated the patch on the reviewboard to match current git master. If you want a version for 4.8, version 5 is the correct one.
I still have to try (i'm out right now), but will do asap, thanks!
I forgot to update the bug report, sorry. Seems that the problem is solved, thanks.