1148856 - windows aero disabled causes issues on smoothscrolling/scrolling performance

Status: NEW

(Core :: Graphics, defect)

Description

[fredgido]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150327030212

Steps to reproduce:

disable windows aero


Actual results:

scrolling performance is horrible and gpu utilization increases to 80% autoscrolling


Expected results:

equal scrolling performance

video of the problem (60fps) https://www.youtube.com/watch?v=NnkpaVrrdtA
problem is not solved by forcing the framerate of the layout/compositor to my screen frequency

Comment 1

[fredgido]

Tested with a new profile.

Comment 2

[Markus Stange [:mstange]]

The memory increase also seems unhealthy. It's shown in the video starting at 0:40.

Comment 3

[Mason Chang [Inactive] [:mchang]]

Does this still occur on release builds or only nightly?

Does it help if you disable these two prefs in about:config:

gfx.vsync.hw-vsync.enabled
gfx.vsync.compositor

Set all the gfx.vsync.* prefs to false and restart nightly. Does the same issue occur?

Comment 4

[fredgido]

stable firefox 36.0.4 32bits occurs (those pref aren't present on stable)

last nightly 64bits occurs with the prefs you told


Some stuff I messed:
I found out if I use a giant image to scroll around instead of a webpage it gets the GPU to 95%. And non aero performance is better, it is so much better that i noticed that FF seems to ignore the framerate of the screen or the frame rate in the pref and sets to 60fps.
for this I used this image: http://puu.sh/gTMeU/ec6b0817ed.jpeg
New profile -> Set all the gfx.vsync.* prefs to false and restart nightly. + set compositor and layout framerate to 144fps.
Then I turned on the performance dev tool on the stable version:
no aero http://puu.sh/gTN0x/ccb7e01832.png vs aero http://puu.sh/gTN2w/26e5943999.png
nightly:
http://puu.sh/gTNhK/65e0d1ab78.png vs http://puu.sh/gTNwZ/e98f0baed6.png

paint times from 0.5 ms to 2 ms or 16.6ms to 17.5ms http://puu.sh/gTOQR/9ad83fb8a9.png vs paint times from 0.5ms to 0.8 ms http://puu.sh/gTOUm/33909aea0f.png

With these paint times with no aero close to 16.7ms seems like it wants to paint at 60hz?.
Retest at 60hz:
New profile -> Set all the gfx.vsync.* prefs to TRUE and restart nightly. + check compositor and layout framerate are -1.

nightly no aero http://puu.sh/gTP3k/34045cb92c.png vs aero http://puu.sh/gTP3I/d39abc8d38.png

This was the time I saw scroll with no aero at the best (because I was scrolling in a image and not a site) seemed like 60fps with A LOT of tearing and some drops. You could see the tear lines going up!
On a website still the same mess: http://puu.sh/gTPxP/a4578f55ec.png

Package of all the performance recordings:  
http://puu.sh/gTPD5/c7e1e9f362.7z

PC specs: i7 920@ 3.67Ghz      AMD HD5850 10GB ram
1080p screen at 60/72/96/120/144HZ

Comment 5

[Mason Chang [Inactive] [:mchang]]

Can you attach your about:support to this bug please?

Comment 6

[fredgido]

Attachment: aboutsupport.txt

Comment 7

[fredgido]

From what I read this problem is possibly caused by the vsync implementation that just calls DwmFlush() to fire a timer after every vblank event. With DWM turned off I think it uses more unreliable timer than DwmFlush().
Can anyone confirm if this is true?

Comment 8

[Mason Chang [Inactive] [:mchang]]

(In reply to fredgido from comment #7)
> From what I read this problem is possibly caused by the vsync implementation
> that just calls DwmFlush() to fire a timer after every vblank event. With
> DWM turned off I think it uses more unreliable timer than DwmFlush().
> Can anyone confirm if this is true?

The vsync implementation is as you describe, but it shouldn't be any worse than what we had before vsync. Software timers are generally worse than hardware timers, so it really should be roughly equal to what you had with Firefox 38. I noticed in the test that you dynamically disabled the DWM while Firefox was still open. This might be causing the problem.

If you disable the DWM then restart firefox, do you still have the same problem? Thanks!

Comment 9

[fredgido]

(In reply to Mason Chang [:mchang] from comment #8)
> If you disable the DWM then restart firefox, do you still have the same
> problem? Thanks!

Yes I do. This occurs with DWM off or aero off.

I came back to this because I noticed when scrolling and when this bad scrolling occurs the cdd.dll is working a lot. This usage of cdd.dll does not happen when scrolling with windows aero on. 
So I thought firefox is falling back so some old method of refreshing the window? Because cdd.dll is related to windows GDI.

I am don't know how firefox works but it might be disabling the layers hardware acceleration when aero is off. Can anyone knowledgeable verify if firefox fallsback from layers hardware composition to GDI when aero is off?

Thanks 

http://i.imgur.com/hnzxXub.png