1204848 - slow scroll while swithing tab is fast (even on simple page)

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect)

Description

[sp31415]

Attachment: Xorg.0.log

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

Hi,
I would like to submit a performance issue.
I'm using Debian Jessie (stable) with am64. Everything is up-to-date.
My GC is nvidia 5700GO (with nouveau) and CPU is Athlon 3400+ (a mono-core one).

My issue is when I scroll a web page, it is terribly slow. In order to scroll twice 3 lines it will take at least 2 seconds and the cpu will be busy at 100%. The busy process is Xorg.
Tab switching is fast, my problem is only for vertical scrolling (maybe horizontal too).
(even scrolling about:support page is slow)

I downloaded the latest firefox release from your site and I created a new profile, issue is still present.

I really want to keep using mozilla product. But for the moment, i will switch to chromium (which provide decent rendering performance).

Feel free to ask anything that can be done by me.
According to my research the problem should be in rendering.

I don't really know how to reproduce, but it is always present on my system. Xorg logs didn't report any error.

Regards,
Serge


lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation NV36M [GeForce FX Go5700] (rev a1)

about:support > Graphics
Description de la carte	nouveau -- Gallium 0.4 on NV36
Fenêtres avec accélération graphique	0/1 Basic (OMTC) Bloqué pour votre carte graphique à cause de problèmes non résolus du pilote.
ID du périphérique	Gallium 0.4 on NV36
ID du vendeur	nouveau
Prise en charge matérielle pour le décodage H264	false
Rendu WebGL	Bloqué pour votre carte graphique à cause de problèmes non résolus du pilote.
Version du pilote	1.5 Mesa 10.3.2
windowLayerManagerRemote	true
Zoom/Panoramique asynchrones	aucun
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0



Actual results:

I upgraded my system and firefox (5 versions up)


Expected results:

scroll should be a bit faster

Comment 1

[Loic]

Could you try to follow https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem to report a perf issue, please.

Comment 2

[Abe - QA (:Abe_LV)]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Nightly 46.0a1 Build ID:20151214030220
and Firefox 42.0

Thanks for taking the time to report this bug.

Are you still able to reproduce this issue in the latest version ?

Comment 3

[Abe - QA (:Abe_LV)]

Closing this as incomplete due to inactivity and lack of response from the reporter. Please feel free to reopen the bug if the issue still reproduces on a current build. Thanks

Comment 4

[sp31415]

To Loic:
https://cleopatra.io/#report=30d35035bc08f51658c2821e2ba7215ff501769e

I have made some tests:
release - 44.0.2 : unusable (slow scroll)
beta - 45.0b10 : unusable (slow scroll)
dev edition - 46.0a2 : better but still unusable (slow scroll)
nightly - 47.0a1 : usable (scroll is regular but cpu is 100 % used and I can't watch any video, great for text)

Comment 5

[Loic]

I'm not the right person to check profiler logs.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Async Pan Zoom (APZ) is enabled on Nightly, which is probably why you're seeing better scrolling performance - I suspect that's likely masking the overarching issue here.

Can you please disable it by going into about:config and switching:

layers.async-pan-zoom.enabled

to false.

Can you confirm that the performance issue resurfaces with that setting? And if so, can you gather a new profile with that setting still set to false?

Comment 7

[sp31415]

nightly - 48.0a1 - layers.async-pan-zoom.enabled=false : I don't have any issue, and performance are better. When scrolling, a partially blank screen has been displayed only once.
With layers.async-pan-zoom.enabled=true, I often see a partially blank screen for one or two seconds.
I tries the dev edition in version 47.0a2 (new version), which is usable (I can scroll).

I believe that I will have to expect version 47 in channel 'release'
Thanks

Comment 8

[Mike Conley (:mconley) (:⚙️)]

One more thing for you to try, sp31415 - would you mind trying release or beta (where things are slow and unusable), and set layers.offmainthreadcomposition.enabled to false, and then restarting? Does that seem to affect your performance?

Comment 9

[sp31415]

I tried release with layers.offmainthreadcomposition.enabled to false.
It improves performance but the result is still unusable.
Thanks

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Okay, so let me see if I can summarize:

Disabling OMTC (setting layers.offmainthreadcomposition.enabled to false) does not fix the issue. Disabling APZ (setting layers.async-pan-zoom.enabled to false) does.

Alright, I think I'm going to try to get this on the APZ team's radar.

kats - is there a good place to put this bug? Other information we should try to get from sp31415?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

(In reply to sp31415 from comment #4)
> To Loic:
> https://cleopatra.io/#report=30d35035bc08f51658c2821e2ba7215ff501769e
> 
> I have made some tests:
> release - 44.0.2 : unusable (slow scroll)
> beta - 45.0b10 : unusable (slow scroll)
> dev edition - 46.0a2 : better but still unusable (slow scroll)
> nightly - 47.0a1 : usable (scroll is regular but cpu is 100 % used and I
> can't watch any video, great for text)

dev edition 46 and nightly 47 both had APZ enabled, and it sounds like it helped somewhat compared to non-APZ (release 44, beta 45). From this it sounds like APZ helped a little (in 46 and 47) and something else in 47 helped significantly more.

(In reply to sp31415 from comment #7)
> nightly - 48.0a1 - layers.async-pan-zoom.enabled=false : I don't have any
> issue, and performance are better. When scrolling, a partially blank screen
> has been displayed only once.
> With layers.async-pan-zoom.enabled=true, I often see a partially blank
> screen for one or two seconds.

Can you confirm that you restarted the browser after changing layers.async-pan-zoom.enabled? The pref only takes effect after a browser restart. You can also check the status of APZ by going to about:support and looking at the "Asynchronous Pan/Zoom" under the Graphics section.

> I tries the dev edition in version 47.0a2 (new version), which is usable (I
> can scroll).

Again this does sound like something in 47 fixed the issue for you.

> I believe that I will have to expect version 47 in channel 'release'

That sounds correct. However the "something" that landed in 47 might be part of the APZ code or it might not, it's not yet clear to me from your responses. If it is part of the APZ code then it might not necessarily be fixed in release 47, because APZ might not be in release 47. (APZ and e10s, which it depends on, will be enabled for a portion of the beta 47 population, but likely will be disabled before release). However the "something" in 47 is not part of the APZ code, then yes, it should be fixed in release 47 as well.

So to confirm, please use Dev Edition 47 or Nightly 48, disable e10s and APZ (you can go to about:preferences and uncheck the "Enable multi-process" checkbox, and restart the browser), and see if the issue is still fixed. If it is, great! If the unusable scroll comes back, then the fix may not be in release 47, but will definitely be in some later release.

Comment 12

[sp31415]

> Can you confirm that you restarted the browser after changing layers.async-pan-zoom.enabled?
Yes, I confirm

nightly - disable e10s and APZ: usable, and scroll is very fluid
nightly - enable e10s and APZ : usable, but it's less fluid

I hope that APZ's performance will be improved before the released, I often get a third or half of my screen to be displayed as blank for one second.
It is acceptable for test but not really in a production environment.

If I can help to improve performance, I will do.

Thanks

Comment 13

[Kartikaya Gupta (email:[e-mail])]

(In reply to sp31415 from comment #12)
> > Can you confirm that you restarted the browser after changing layers.async-pan-zoom.enabled?
> Yes, I confirm
> 
> nightly - disable e10s and APZ: usable, and scroll is very fluid
> nightly - enable e10s and APZ : usable, but it's less fluid

Great, thanks! So it sounds like the issue is fixed in 47 with or without e10s/APZ, but APZ makes things a little worse for you.

> I hope that APZ's performance will be improved before the released, I often
> get a third or half of my screen to be displayed as blank for one second.

This sounds like checkerboarding, which is the expected result when scrolling faster than the browser can paint. However, it sounds like you're encountering this a lot, and maybe there's something we can improve here.

> It is acceptable for test but not really in a production environment.
> 
> If I can help to improve performance, I will do.

Yes, please. Once you encounter one of these "screen going blank" issues (ideally one of the longer/more severe ones), go to about:checkerboard, and find the report that corresponds to that event - you'll need to check the timestamps to locate it. Then click on the report, copy the raw log from the textarea at the bottom of the page, and attach it (as an attachment please) to this bug. That will give us some more information about why you saw the checkerboarding, and can help us improve the performance.

> Thanks

Thank you!

Comment 14

[sp31415]

Attachment: 160407_checkerboard_noticed.txt

checkerboard that I 'see'

Comment 15

[sp31415]

Attachment: 160407_checkerboard_most_severe.txt

The most severe checkerboard of the day, but I don't remember it

Comment 16

[sp31415]

Attachment: 160408_checkerboard_another.txt

The blank screen was half of the screen.

Comment 17

[sp31415]

I attached a few log.
I have the feeling that very few blank screen are producing a checkerboard. And quite a lot didn't produce that.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

The reports you've posted so far all seem to point to long paint times as the problem. We have some work to do in that area, so it's not entirely surprising. APZ does make paint times worse because there is a larger area to paint.

(In reply to sp31415 from comment #17)
> I attached a few log.
> I have the feeling that very few blank screen are producing a checkerboard.
> And quite a lot didn't produce that.

This is surprising to me. If you see this again can you please provide the URL of the page that you see it on?

Comment 19

[sp31415]

Attachment: 160419_checkerboard.txt

url: http://www.nextinpact.com/news/98496-condamne-pour-son-selfie-avec-jean-marie-le-pen-dormant.htm

Comment 20

[sp31415]

> long paint times as the problem

As I indicated in my first post cpu is quite old and monocore (Athlon 3400+ with 2GB Ram)
It may have impact.

Comment 21

[Kartikaya Gupta (email:[e-mail])]

(In reply to sp31415 from comment #19)
> Created attachment 8743192 [details]
> 160419_checkerboard.txt
> 
> url:
> http://www.nextinpact.com/news/98496-condamne-pour-son-selfie-avec-jean-
> marie-le-pen-dormant.htm

The report here shows a 2-second paint time, which is pretty long. Unfortunately there's no quick fix for this, and regular checkerboarding issues are covered by bug 1256677 and its dependencies. Note also that if you feel the checkerboarding is excessive, you can disable APZ entirely to go back to main-thread scrolling which will not have checkerboarding.

Unless there's anything else mysterious about this bug, I think the main issue you were complaining about (the slow scrolling) has been resolved (in Firefox 47 and up) and we can close this bug.

Comment 22

[sp31415]

Attachment: 160427_checkerboard.txt

a severe checkerboard
http://www.courrierinternational.com/dessin/etats-unis-femmes-entre-le-sexe-et-lalcool-il-faut-choisir?utm_campaign=&utm_medium=email&utm_source=Courrier+international+au+quotidien

Comment 23

[sp31415]

You can close it.
bug can be considered as corrected since performance are acceptable.
I don't care about having some checkerboards per day.
I only have one remaining question: If I have a severe checkerboard, what is the correct way to submit it ?

Thanks

Comment 24

[Kartikaya Gupta (email:[e-mail])]

(In reply to sp31415 from comment #23)
> If I have a severe checkerboard, what is
> the correct way to submit it ?

In general, file a new bug with the log. However in practice it is very unlikely we will be able to fix individual checkerboarding occurrences, because it's a balancing act where fixing some occurrences will make others worse. See bug 1256677 comment 0 for details.