Open Bug 1163301 Opened 9 years ago Updated 2 years ago

Silk in software mode should attempt to run at native display refresh rate before using hardcoded 60 Hz

Categories

(Core :: Graphics, enhancement)

enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: jamcnair, Unassigned)

References

()

Details

(Whiteboard: gfx-noted)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150415140819
When Silk can't get a hardware v-sync source, it should make a reasonable attempt at running the vsync refresh driver and compositor at current display's native display refresh rate before using a hard-coded 60Hz. Otherwise, there is subtle judder on high refresh displays OR smearing on low refresh displays, because Firefox is not displaying frames consistent with the display's native refresh rate.
Severity: normal → enhancement
Component: Untriaged → Graphics
Flags: needinfo?(mchang)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Summary: Software vsync refresh driver should try to get native display refresh rate before using hardcoded 60 Hz → Silk in software mode should attempt to run at native display refresh rate before using hardcoded 60 Hz
Flags: needinfo?(mchang)
Depends on: 116303
Depends on: 1163303
No longer depends on: 116303
I'm wondering how this would work in practice. From comment 1, if we don't run the refresh driver and compositor at the native display rate, we get judder or smearing. Is this happening on Firefox Release, which doesn't have silk? 

Both of those components before Gecko 39 are using hardcoded 60 fps. I'm not sure that even if we do match the current display's rate, we wouldn't have this problems since we're not actually synced to vsync. We might match the rate, but the timing would still be off, which means these problems would still occur. Slight Jank is expected as well as smearing, but that's due to not being aligned to vsync versus the rate at which we render. Do these problems happen on Firefox release today (Gecko 37)? Thanks!
Flags: needinfo?(jamcnair)
This is a problem on Firefox release today, and is noticeable to people who are sensitive to frame rate changes (like video editors). The key here is frame consistency or cadence. Here is an extremely contrived example. 

Each letter is a displayed frame
The dashes are the v-blank at the correct ratio of 60:75 == 4:5

|--G-----G-----G-----G-----| Current Gecko at 60 Hz: 4 gecko frames for every 5 display frames
|D----D----D----D----D----D| Display at native 75 Hz
|--S----S----S----S----S---| Software Silk @ 75 Hz


Each gecko frame displays at a slightly different moment during the v-blank, leading to partially drawn/composite frames that change all the time.
Silk in software mode matching the 75 Hz display rate. The frames are still misaligned, BUT they are consistent, increasing perceived smoothness. 

Really, I'm not bashing all your hard work. In a perfect world, everything has perfect, hardware v-sync notifications. I just feel this is a better compromise, if it doesn't require an enormous amount of work.

Thanks!
Flags: needinfo?(jamcnair)
Sorry if I was unclear. Manually changing layout.frame_rate, to match a monitor's native refresh rate, does result in an improved experience here and now, in Gecko release. Again, this is limited testing for a very particular audience. Even though the frames aren't perfect, they are still consistent. 

Some of my users also claim that Gecko at 75Hz is "more responsive", but I haven't observed that. 

And if I didn't say it, thanks again for Hardware v-sync Silk. Using Nightly is like using a whole new browser.
(In reply to J-Mackerel from comment #4)
> Sorry if I was unclear. Manually changing layout.frame_rate, to match a
> monitor's native refresh rate, does result in an improved experience here
> and now, in Gecko release. Again, this is limited testing for a very
> particular audience. Even though the frames aren't perfect, they are still
> consistent. 
> 
> Some of my users also claim that Gecko at 75Hz is "more responsive", but I
> haven't observed that. 
> 
> And if I didn't say it, thanks again for Hardware v-sync Silk. Using Nightly
> is like using a whole new browser.

No offense taken! Glad you're experiencing a better Firefox! 

Hmm, it's interesting that it feels "more responsive". I assume you're testing on Gecko release for 75 hz? Is this on Windows? 

I think I'd be more inclined to do https://bugzilla.mozilla.org/show_bug.cgi?id=1138627#c6, or some variation of it. Would you still prefer to use a custom software vsync rate over the default hardware vsync rate in terms of overall rate preference?
(In reply to Mason Chang [:mchang] from comment #5)
> No offense taken! Glad you're experiencing a better Firefox! 
> 
> Hmm, it's interesting that it feels "more responsive". I assume you're
> testing on Gecko release for 75 hz? Is this on Windows? 
> 
> I think I'd be more inclined to do
> https://bugzilla.mozilla.org/show_bug.cgi?id=1138627#c6, or some variation
> of it. Would you still prefer to use a custom software vsync rate over the
> default hardware vsync rate in terms of overall rate preference?

All of this is on (various) versions of Windows (Vista -> 7 -> 8.1). Running release Firefox higher than 60 Hz on monitors that support it is overall more pleasing. However, I've recently demo'ed Nightly to several people here and they overwhelmingly prefer Silk, especially at 75 Hz. This is, of course, when the drivers work (which is NOT Mozilla's fault :P).  For overall rate preference, something like https://bugzilla.mozilla.org/show_bug.cgi?id=1138627#c6 is perfect, because it preserves a power-user feature which I already use, while the best experience remains default.
Whiteboard: gfx-noted
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.