https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #33 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #32)
(In reply to lei.pero from comment #31)
It's still odd behaviour, in both cases Chrome caps FPS to refresh rate (this case 85FPS),
Sounds like Chrome just has its own framerate throttling which works independently from sync-to-vblank.
but using DRI3 using mutter/clutter, for some reason it creates continuous stutters, even tho FPS is the same and all other parameters are equal. It really looks (when viewed live) as if FPS is not equal to refresh rate.
It's possible that the mutter framerate doesn't match the refresh rate (you can check by setting GALLIUM_HUD=fps for the mutter process), but it's also possible it's simply due to unfortunate interaction between the Chrome and mutter frame timings.
[...] it is still probably mutter/clutter configuration problem in the code (since it happens only there), it doesn't follow configuration in .drirc as other WM's.
Not really. By setting vblank_mode=0, you're forcing mutter to run in a way it doesn't intend. If doing so breaks something, that can hardly be considered a mutter bug, and you get to keep all the pieces. :)
You might be very right about unfortunate interaction between Chrome (and Chromium) and mutter frame timings, since I did tried "CLUTTER_DEFAULT_FPS=85" (and 84) env. value and it made 0 difference.
Yeah, but by setting 1 and using any other WM results in Chromium/Chrome being VSYNC-ed, or at least it looks like it is, there's no tear line and picture is smooth as it can be (while on mutter/clutter there's tear line), so for the sake of standardisation i would call it mutter/clutter configuration bug that will probably stay unresolved, plus it doesn't explain DRI2 behavior that follows same standard :).