Great progress has been made by closing this: https://bugs.kde.org/show_bug.cgi?id=293044 But compton compositor shows that things could go even better! Reproducible: Always Steps to Reproduce: 1. Activate kwin vsync to true, and opengl vsync to true (via .drirc or nvidia-settings) 2. Use opengl compositing 2. restart kwin just to be sure 3. use firefox to open http://www.repubblica.it/index.html 4. Scroll the page until the end so that it loads all of the content ( <- DO THIS!) 5. Scroll the page by pushing on the scrollbar button 6. set general.autoScroll to true in about:config and scroll by pushing the middle mouse button to make the effect more evident. Actual Results: See that the page jumps from time to time. Expected Results: The scrolling could be smoother If you deactivate the kwin effects, and use compton compositor from git and start it this way: # compton -c -r4 -l-6 -t-4 -z -G -C -e0.85 -f -D30 -I0.45 -O0.45 --paint-on-overlay --unredir-if-possible --backend glx --glx-no-stencil --glx-no-rebind-pixmap --vsync opengl And repeat the steps, you'll see a very smooth scrolling, with almost no jumps at all. I was able to reproduce the kwin jerkiness and the compton smoothnes on three systems. With an Intel 945gm and Kwin, scrolling was nearly unusable with compton was perfect. With an 9500GT and nvidia blob, Kwin is a little jumpier than compton With an ati 7500 +OSS drivers on a poor PIII 3.0ghz, compton was really smooth too (didn't tried kwin) Other useful info: Firefox version 20.0.1 with smooth scrolling active kwin effects: zoom,highlight window,login,logout,magic lamp,maximize,screenshot,sliding popups,taskbar thumbnails,translucency,wobbly windows,startup feedback,dialog parent,dim screen for administration mode,cover switch,desktop grid,outline,present window,resize window kwin backend: opengl kwin graphicssystem: raster (tried native too, no difference) firefox is the frontmost window
I just repeated the steps with the monitor set to 75hz instead of 60 and Just noticed that the wkin jerkiness is more evident. This time even compton is not perfect (but still better), because probably firefox renders at 60hz. So just set layout.frame_rate to 75 in about.config and restart firefox (required). Unfortunately kwin jerkyness is still superior to the same configuration at 60hz, but compton remains smooth like butter.
glWaitVideoSync being used for vsync does not work, vsyncing is currently completely reworked for 4.11
Good to know, thanks for answering !
I compiled kdebase-workspace from git and tried the new Tearing prevention options with and without vsync in nvidia-settings. The best option for me was "only when cheap", but i still have the jumpy scrolling and i didn't noticed any improvment over kde 4.10.2 * Maybe the following could help: It is not just this, if i completely disable kde desktop effects and repeat the test, the "tearing line(s)" stays fixed in a place, probably because firefox is updating exactly at 60hz. Compton without the --vsync opengl performs the same; the tearing line stays in place. But if i enable kde desktop effects without any vsync, the tearing lines moves fast around the page, and this happens with xrender backend too. Setting RefreshRate=60 and MaxFPS=120 in kwinrc makes the tearing line more stable, but it still slowly moves down, and with vsync enabled on "only when cheap", the jumpyness (still higher than compton) is less evident. So, it seems to me that
Ops: ...So, it seems to me that there is some kind of desyncronization somewhere. Hope this helps.
1st: this is still "in progress" - there're two more patches in review and another two on my HDD. 2nd: if your FF uses GL there's a battle of the GL contexts (forth and back between FF and KWin) and if your GPU is not up to this (because FF tries to repaint as often as possible) and esp. if both devices block independently for sync purposes, you might drop frames - this is inevitable and not fixable (though the wayland protocol bypasses this issue) This: > if i completely disable kde desktop effects and repeat the test, the "tearing line(s)" stays fixed in a place means that the client (FF) uses OpenGL and glWaitVideoSync and copies pixels or subbuffers - what does not work (as we figured) because the copying isn't fast enough (getting us the exact same results) W/ compositing the client has no clocked output device (its "screen" is now the compositor) and no syncing within the client works (though it might still falsely block for random amounts of time) 3rd: what the heck is "compton"? (aside the photoelectric effect...) - do you mean compiz? 4th: "only when cheap" means that you only get sync'd output if "nearly" the entire screen is updated anyway - so scrolling in a maximized FF will be different from scrolling in a quarter sized FF. 5th: on the nvidia blob and with 4.11 (not current git - "WIP") ensure to enable TripleBuffering in org.conf
1st: thanks :D 2nd: My firefox doesn't use opengl, Hw acceleration is disabled by default and i've no forced it in anyway, i am 100% sure. Instead, it uses an internal timer that you can override by setting layout.frame_rate to an integer in about:config (see comment1) 3rd: compton is a fork of xcompmgr with opengl support and other things. i decided to open this 'bug' after seeing how smooth could firefox scroll in a composite environment, really, take a look: https://github.com/chjj/compton if you want to try, please, use *all* of the options i provided in the previous posts. 5th: i assume there's no way (by now) to try or can i download something? Thanks.
For compton, see also this, starting from post #3: https://bbs.archlinux.org/viewtopic.php?id=161403
compton behaves *exactly* like kwin here (every few frames there's a jump) i activated hw acceleration in FF and also the the FF fps counter -> it does not maintain 60FPS here (but flows between 45 & 55 fps, compositing or not, whether kwin or compton) what means that it shifts against 60fps and everytime this shift wraps, you get a "jump" -> can you please check whether FF actually maintains 60FPS for you?
With Hw acceleration active, i get 45-55fps with kwin, and 55-75(!) with compton, this on a new machine with a 9800gt. With hw acceleration active, kwin and compton are both jumpy, but kwin seems less responsive. As usual, without hw acceleration, compton makes ff scrolls like butter, while with kwin it is jumpy. Are you sure you testes exactly the compton options i gave you? Could you run this too: http://sliste.sl.funpic.de/bmark/ ...and after the 'benchmark', try to scroll the page with smooth scrolling active? here there's huge difference.
(In reply to comment #10) > Are you sure you testes exactly the compton options i gave you? Yes, i "risked" to cnp the command ;-) Given the findings of the uncomposited FF, this isn't much surprising either. You'd need to invoke motion blurring to "smooth" that away. My guess is that for FF SW rendering, it becomes sort of a CPU limitation. Try KWIN_NVIDIA_HACK=0 __GL_YIELD=USLEEP kwin --replace & This will move more CPU slices from the nvidia driver to the kwin core. The default of KWIN_NVIDIA_HACK=1 causes __GL_YIELD=NOTHING what i personally doubt to be a good idea. > ...and after the 'benchmark', try to scroll the page with smooth scrolling > active? here there's huge difference. Humm? You mean like "running the benchmark alters the performance of smooth scrolling" - sounds like power saving?
KWIN_NVIDIA_HACK and __GL_YIELD didn't helped. Don't forget that i've the same results on intel hw too (a poor gm945) Anyway, i just restarted Xorg, and firefox + kwin started to performs a lot better on nvidia. gm945 is still jerky when scrolling with kwin, while compton works perfectly. I posted you that benchmark page, not for the benchmark, but just because is a long page without graphic. firefox+compton+gma945 scrolls at 60hz without issues, while firefox+kwin+gma945 is jumpy
(In reply to comment #12) > Anyway, i just restarted Xorg, and firefox + kwin started to performs a lot > better on nvidia. Well, does that mean the evironment had impact or not? > gm945 is still jerky when scrolling with kwin, while compton works perfectly. > > I posted you that benchmark page, not for the benchmark, but just makes no difference here between compton and kwin - can't since even HW accelerated FF does not make 60FPS, so i tend to doubt that it would on SW. -> both "jump" few frames when running the benchmark (where uncomposited + FF SW is ~16500, kwin+nvidia+"only when cheap" on maximized FF is ~14500 and compton wizth your command and vsync in nvidia-settings and triple buffering enabled is ~11500...) As for the gma, it'll (using "only when cheap"?) pot. use subbuffer copying, invoking a "malicious" waitSync()" "Unfortunately" my gma945 sits on top of an Atom - i frankly doubt (no FF installed there) that the CPU will make 60FPS there ever ;-) Please ping back in about a week or so on whether the pending patches have been pushed.
(In reply to comment #13) > > > Anyway, i just restarted Xorg, and firefox + kwin started to performs a lot > > better on nvidia. > > Well, does that mean the evironment had impact or not? If you mean the environment variables, no; they don't probably there was some leak gone when i restarted xorg, can't say > > gm945 is still jerky when scrolling with kwin, while compton works perfectly. > > > > I posted you that benchmark page, not for the benchmark, but just > > makes no difference here between compton and kwin - can't since even HW > accelerated FF does not make 60FPS, so i tend to doubt that it would on SW. Mh, here Hw accelerated firefox is slower (9500GT speaking right now...) > -> both "jump" few frames when running the benchmark (where uncomposited + > FF SW is ~16500, kwin+nvidia+"only when cheap" on maximized FF is ~14500 and > compton wizth your command and vsync in nvidia-settings and triple buffering > enabled is ~11500...) At least compton seems faster in completing the bench, but i posted that page to evalutate the smoothness, rather than speed; what i meant was to observe it with smooth scrolling active and scrolling with the mouse, rather that the bench itself. > > As for the gma, it'll (using "only when cheap"?) pot. use subbuffer copying, > invoking a "malicious" waitSync()" Now you're speaking too technical to me :) Anyway i tested the plasma-workspace-git only on nvidia; can't say nothing about gma. > "Unfortunately" my gma945 sits on top of an Atom - i frankly doubt (no FF > installed there) that the CPU will make 60FPS there ever ;-) Yes, my netbook with a poor atom performs bad with compton and kwin. When I was speaking about GMA, i was referring to a centrino notebook > Please ping back in about a week or so on whether the pending patches have > been pushed. Any hint on how to be sure they landed? Another thing: Are you doing that tests with triplebuffering active? I'm asking because i dont / nor i know how to enable triple buffering on the GMA.
(In reply to comment #14) > At least compton seems faster in completing the bench interesting - so either compton and kwin are *faster* than the completely uncomposited condition? > Anyway i tested the plasma-workspace-git only on nvidia; can't say nothing about gma. Ok, so atm. nvidia + git is no more issue? pre-git synced code is pointless to operate on anyway (and even the git version has some change requirements ahead) > Any hint on how to be sure they landed? If you ask, i'll tell you - i'd just probably forget if i'd promise to notify you ;-) > Another thing: > Are you doing that tests with triplebuffering active? Yes. > I'm asking because i dont / nor i know how to enable triple buffering on the GMA. It seems triple buffering is now by default enabled for intel GPUs. Option "TripleBuffer" "false" in xorg.conf would disable it (see man:intel) The pending patches include runtime detection of triple buffering availability.
(In reply to comment #15) > interesting - so either compton and kwin are *faster* than the completely > uncomposited condition? Nope, i was just referring to your benchmark results. > Ok, so atm. nvidia + git is no more issue? > pre-git synced code is pointless to operate on anyway (and even the git > version has some change requirements ahead) No issue (or at least, things are a lot better, 'almost' like compton) even in 4.10.2 after restarting xorg;
(In reply to comment #16) > (In reply to comment #15) > > interesting - so either compton and kwin are *faster* than the completely > > uncomposited condition? > > Nope, i was just referring to your benchmark results. Yes, but what stunned me, is that either compositing performs better than no compositing (i was frankly under the impression that higher numbers would mean "better")