Commen=
t # 33
on bug 99418<=
/a>
from lei.pero@gmail=
.com
(In reply to Michel D=C3=A4nzer from comment #32)
> (In reply to lei.pero from comment #31)
> > It's still odd behaviour, in both cases Chrome caps FPS to refres=
h rate (this
> > case 85FPS),
>=20
> Sounds like Chrome just has its own framerate throttling which works
> independently from sync-to-vblank.
>=20
>=20
> > but using DRI3 using mutter/clutter, for some reason it creates
> > continuous stutters, even tho FPS is the same and all other param=
eters are
> > equal. It really looks (when viewed live) as if FPS is not equal =
to refresh
> > rate.
>=20
> It's possible that the mutter framerate doesn't match the refresh rate=
(you
> can check by setting GALLIUM_HUD=3Dfps for the mutter process), but it=
's also
> possible it's simply due to unfortunate interaction between the Chrome=
and
> mutter frame timings.
>=20
>=20
> > [...] it is still probably mutter/clutter configuration problem i=
n the code
> > (since it happens only there), it doesn't follow configuration in=
.drirc as
> > other WM's.
>=20
> Not really. By setting vblank_mode=3D0, you're forcing mutter to run i=
n 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=3D85"
(and 84) env. value and it made 0 difference.
Yeah, but by setting 1 and using any other WM results in Chromium/Chrome be=
ing
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 th=
at
will probably stay unresolved, plus it doesn't explain DRI2 behavior that
follows same standard :).