Bug 293044 - Kwin + opengl compositing make firefox scrolling jerky.
Summary: Kwin + opengl compositing make firefox scrolling jerky.
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 4.8.0
Platform: Archlinux Linux
: NOR normal with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2012-02-01 12:55 UTC by Antonio Orefice
Modified: 2012-09-03 12:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

glxinfo (27.67 KB, text/plain)
2012-02-10 16:12 UTC, Antonio Orefice
Xorg.0.log (19.96 KB, text/plain)
2012-02-10 16:13 UTC, Antonio Orefice

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Orefice 2012-02-01 12:55:50 UTC
Version:           4.8.0 (using KDE 4.8.0) 
OS:                Linux

As suggested here:

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
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.
Comment 1 Antonio Orefice 2012-02-01 13:28:48 UTC
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.
Comment 2 Philipp Knechtges 2012-02-10 10:30:45 UTC
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?
Comment 3 Antonio Orefice 2012-02-10 11:21:20 UTC
I'm using a simple qtcurve theme, no transparency.
cpu seems to jump to 75% per core, one by X, other by firefox.
Comment 4 Thomas Lübking 2012-02-10 15:39:01 UTC
[ ] 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 ;-)
Comment 5 Antonio Orefice 2012-02-10 16:12:37 UTC
Created attachment 68678 [details]
Comment 6 Antonio Orefice 2012-02-10 16:13:17 UTC
Created attachment 68679 [details]
Comment 7 Antonio Orefice 2012-02-10 16:13:42 UTC
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.
Comment 8 Thomas Lübking 2012-02-10 16:16:53 UTC
Is  it off to an external screen from a notebook?
Comment 9 Antonio Orefice 2012-02-10 16:26:02 UTC
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.
Comment 10 Thomas Lübking 2012-02-10 16:34:24 UTC
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...)

Comment 11 Antonio Orefice 2012-02-10 16:50:41 UTC
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!
Comment 12 Antonio Orefice 2012-02-16 13:02:11 UTC
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')
Comment 13 Antonio Orefice 2012-02-16 15:19:29 UTC
Oh, with the patch zoom plugin flickers likes hell when zooming/panning the view
Comment 14 Thomas Lübking 2012-03-04 01:01:41 UTC
feel free to try an update:
Comment 15 Antonio Orefice 2012-03-05 12:57:14 UTC
I tried and it is glitch free, but scrolling is choppy again (maxfps and refreshrate override fixed it)
Comment 16 Antonio Orefice 2012-03-05 13:34:29 UTC
Please ignore the very previous comment, i was wrong.
Here are some numbers and impressions:

Desktop with windows on both monitors:
Comment 17 Antonio Orefice 2012-03-05 13:47:32 UTC
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.
Comment 18 Thomas Lübking 2012-03-05 23:07:47 UTC
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.
Comment 19 Thomas Lübking 2012-03-12 01:45:50 UTC
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.
Comment 20 Antonio Orefice 2012-03-12 07:13:06 UTC
I still have to try (i'm out right now), but will do asap, thanks!
Comment 21 Antonio Orefice 2012-09-03 12:18:26 UTC
I forgot to update the bug report, sorry.
Seems that the problem is solved, thanks.