1365876 - [e10s] slowness of the effect of the keys Home and End

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[Julien L.]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

On this webpage : http://www.phonandroid.com/forum/
 I type on the keys Home or End.



Actual results:

The scrolling is not direct, I don't go to the top or the bottom of the webpage directly, there is a delay when e10s is enabled.


Expected results:

I should go directly to the top or the bottom of the webpage while using the keys Home or End.

Comment 1

[Julien L.]

Please note that this latency is also in nightly 55. And there is no problem with the mouse wheel scrolling.

Comment 2

[Loic]

Do you have latency with e10s disabled?

Comment 3

[Julien L.]

No, I don't have any latency with e10s disabled...

Comment 4

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

Did this regress since bug 1295019 was fixed? If so, can you use mozregression to find out when it regressed?

Comment 5

[Loic]

Link to use mozregression: http://mozilla.github.io/mozregression/
Make the test for each nightly build downloaded by the tool, enter if it's good or bad, then copy here the final pushlog.
You can start with --good=50 as bug 1295019 has been fixed in 51.

Comment 6

[Julien L.]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> Did this regress since bug 1295019 was fixed? If so, can you use
> mozregression to find out when it regressed?

bug 1295019 was fixed in FF 51. I have just tested this version and the bug was already there. So there is no regression, the bug has never been fixed previously completely.

Comment 7

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

Ok, thanks. I can't reproduce this problem so I'm not entirely sure what's causing it, but the work in bug 1351783 might help.

Comment 8

[Julien L.]

Since bug 1351783 has been fixed, I tried to scroll up and down on the webpage with the keys Home and End, and I see no changes.
BUT I've also noticed some scrolling issues with Chrome for Android on this website so it might only be a website problem...

Comment 9

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

Note that you need to turn on the pref to activate bug 1351783.

Comment 10

[Julien L.]

Okay! What is this pref please? I looked for apz.keyboard.enabled but I found nothing.

Comment 11

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

It is apz.keyboard.enabled, it should be in Nightly builds from Jun 29 (today) onwards.

Comment 12

[Julien L.]

I've turned on the pref and the scrolling with the keyboard is way faster!
But on the web page I mentioned above, when I am at the top of the page and I push the End key, for a few milliseconds the advertisement stays visible : https://screenshots.firefox.com/kBbhkW94baQio2jF/www.phonandroid.com

Comment 13

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

I get different ads on the page so it's hard to tell why you're seeing that. I don't see the ad getting stuck on my machine. Most likely they are using javascript to reposition the ad and so with APZ scrolling it lags behind. Or it might be a bug somewhere, not sure.

Comment 14

[Julien L.]

Should I warn other people in bug 1351783 about this issue?
It looks like this bug is not fixed completely...

Comment 15

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

Could you post a video of the problem? It would be more useful than the screenshot and might allow me to diagnose what is going on.

Comment 16

[Julien L.]

Here's a video when apz.keyboard.enabled is set to True : http://ratm6.free.fr/captures%20d%27ecran/nightly_56_scrolling_apz_keyboard.mp4
That's a new issue : you can see a black screen sometimes when I push the Home and End keys.

Comment 17

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

That looks like checkerboarding to me, which is expected on pages that we can't paint fast enough.

Comment 18

[Julien L.]

So it's due to my hardware specs or graphics driver? What Mozilla can do for that?

Comment 19

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

If you get a Gecko profile while scrolling it might point to things we can improve.

Comment 20

[Julien L.]

Here it is : https://perf-html.io/public/23dcde09081fb9ac396e5fcddc50114632578cee/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-6-1-5

Comment 21

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

Was this taken from a mozilla Nightly build? It doesn't seem to be symbolicated properly.

Comment 22

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

Regardless it seems like we're spending a lot of time (about 2% of total time in Content Process #3) in nsTextFrame::PaintOneShadow. Mason, you know stuff about shadows, any thoughts here? (profile is in comment 20)

Comment 23

[Mason Chang [Inactive] [:mchang]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #22)
> Regardless it seems like we're spending a lot of time (about 2% of total
> time in Content Process #3) in nsTextFrame::PaintOneShadow. Mason, you know
> stuff about shadows, any thoughts here? (profile is in comment 20)

Looks like about half the time is spent in the driver, which might just be unlucky here. As for text shadows, I wasn't sure how we could actually speed them up. We create a temporary surface, draw the glyph into the temporary surface, then blur it. It isn't something we can really cache very easily either since the blur depends on what glyph was drawn. The glyphs are already cached. I guess we can try a blurred glyph cache but I'm not sure how often text-shadows are used or if the same characters are used very often either.

Comment 24

[Julien L.]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #21)
> Was this taken from a mozilla Nightly build? It doesn't seem to be
> symbolicated properly.

Yes of course it was taken from the latest nightly build, with the latest geckoprofiler webextension..

Comment 25

[Julien L.]

By the way, is it possible to do something to fix this bug?
Thanks.

Comment 26

[Mason Chang [Inactive] [:mchang]]

Can you please try getting another nightly profile? I really wonder why the symbols here are missing and text shadows are the only ones showing up. Thanks

Comment 27

[Julien L.]

OK so here is the new report : https://perfht.ml/2uzakpI

Comment 28

[Mason Chang [Inactive] [:mchang]]

Thanks! Thats a lot better. Perchance, can you try this:

1) Go to about:config in the  URL bar
2) set the preference "layers.acceleration.disabled" to true.
3) Restart Nightly
4) Try again / profile again?

After you're done, you can reset the preference back to the default. The blur here looks slow because we do a flush and the GPU here gets blocked.

Comment 29

[Mason Chang [Inactive] [:mchang]]

(In reply to Julien L. from comment #27)
> OK so here is the new report : https://perfht.ml/2uzakpI

I'm mostly just wondering if you still have the problem after that preference.

Comment 30

[Julien L.]

With that preference set to True, it solves the problem. But should I use nightly with that pref always set to true in order to avoid graphical problems? I guess not. So I suppose a fix should be made... What do you think about that?
( The gecko profile :
https://perfht.ml/2vyAFBz  )

But as I said in comment 12, when I am at the top of the page and I push the End key, for a few milliseconds the top advertisement (banner) stays visible.
It's another bug I think. If you want another video, you need to tell me which software I should use because for the first one I had Snagit which is a shareware (I don't want to pay to get it). Thanks!

Comment 31

[Mason Chang [Inactive] [:mchang]]

From https://bugzilla.mozilla.org/show_bug.cgi?id=1357692#c7 - Why was 8192 the magic number? 

Should we just disable hardware acceleration blurs for all text shadows in general?

Comment 32

[Lee Salzman [:lsalzman]]

(In reply to Mason Chang [:mchang] from comment #31)
> From https://bugzilla.mozilla.org/show_bug.cgi?id=1357692#c7 - Why was 8192
> the magic number? 
> 
> Should we just disable hardware acceleration blurs for all text shadows in
> general?

It was meant to be a reasonable assumption based on the test-case given by the user and trying to still preserve hardware accel for larger text shadows.

We should check if the fix I did in bug 1365794 addressed this. Since that only landed in 56, the user will have to try with nightly to see if the problem persists there.

Julien, can you try using a recent nightly and see if it is fixed there?

Comment 33

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

His profiles are already from recent Nightlies.

Comment 34

[Mason Chang [Inactive] [:mchang]]

Attachment: Blur text shadows on the CPU

Comment 35

[Mason Chang [Inactive] [:mchang]]

Attachment: Blur text shadows on the CPU

Comment 36

[Mason Chang [Inactive] [:mchang]]

Attachment: Blur text shadows on the CPU

Comment 37

[Lee Salzman [:lsalzman]]

(In reply to Mason Chang [:mchang] from comment #36)
> Created attachment 8887662 [details] [diff] [review]
> Blur text shadows on the CPU

There's one more spot in nsLayoutUtils::PaintTextShadow we need to fix as well: https://dxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?q=nsLayoutUtils%3A%3APaintTextShadow&redirect_type=direct#6019

Comment 38

[Mason Chang [Inactive] [:mchang]]

Attachment: Blur text shadows on the CPU

Comment 39

[Julien L.]

Hello Mason, are you aware of that review? (I do not see any needinfo...?)

Comment 40

[Mason Chang [Inactive] [:mchang]]

Yeah sorry, trees were closed all last week so this slipped under the radar. Thanks!

Try - https://treeherder.mozilla.org/#/jobs?repo=try&revision=1b2c15862ac61469759e3a856a73622de8f2b929

Comment 41

[Julien L.]

Ok but which build should I try? (first time for me to run a try-buid)
I have windows 8.1, there is one build called "opt" and the other one called "debug"...

Comment 42

[Mason Chang [Inactive] [:mchang]]

(In reply to Julien L. from comment #41)
> Ok but which build should I try? (first time for me to run a try-buid)
> I have windows 8.1, there is one build called "opt" and the other one called
> "debug"...

Oh sorry, this was just our internal testing to make sure I didn't break Firefox. You don;t have to try anything.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a75faf9cd6a7
Blur text shadows on the CPU. r=lsalzman

Comment 44

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a75faf9cd6a7

Comment 45

[Julien L.]

Mason, I still got the same issue while scrolling with APZ keyboard on http://www.phonandroid.com/forum/
It appears like this despite the patch : http://ratm6.free.fr/captures%20d%27ecran/nightly_56_scrolling_apz_keyboard.mp4

Moreover, I can't currently use Nightly with security because there is a bug with nightly and Kaspersky antivirus (Bug 1384327).
I'm forced to close my antivirus and I don't like that.

Comment 46

[Julien L.]

Here is a gecko profile for this problem : https://perfht.ml/2uwSFhN   (from another computer)
If the preference "layers.acceleration.disabled" is set to true, it doesn't solve it this time.

Comment 47

[Mason Chang [Inactive] [:mchang]]

(In reply to Julien L. from comment #46)
> Here is a gecko profile for this problem : https://perfht.ml/2uwSFhN   (from
> another computer)
> If the preference "layers.acceleration.disabled" is set to true, it doesn't
> solve it this time.

This profile still shows d2d acceleration happening. Maybe this patch didn't hit the nightlies yet. Is this profile with layers.acceleration disabled set to true? Did you restart nightly. Otherwise I still see acceleration happening with this profile.

Comment 48

[Julien L.]

Unfortunately for now I can't use Nightly (Bug 1384327). Maybe I'll be able to use the other computer later (it's not mine).

Comment 49

[Julien L.]

Hello, 
with layers.acceleration.disabled set to false, apz.keyboard.enabled set to true and latest nightly, the bug is still here.
Here is the gecko profile : https://perfht.ml/2uR7cFo
Do you know what happens?

Comment 50

[Mason Chang [Inactive] [:mchang]]

(In reply to Julien L. from comment #49)
> Hello, 
> with layers.acceleration.disabled set to false, apz.keyboard.enabled set to
> true and latest nightly, the bug is still here.
> Here is the gecko profile : https://perfht.ml/2uR7cFo
> Do you know what happens?

This seems odd. Acceleration is still happening and it looks like this patch didn't work on your nightly. Can you attach your about support?  Does the problem go away with layers acceleration disabled set to true? From comment 46, that preference didn't seem to be working.

Comment 51

[Mason Chang [Inactive] [:mchang]]

So I dug into it a bit more. We're not blurring the text shadow anymore on the GPU, but we're still masking the surface and doing the other parts of the blur that aren't related directly to blurring on the GPU. The GPU here has to flush when it has to materialize the surface to mask it, causing the slowdown. All the time spent is within the GPU driver, so I'm not really sure what else we can do here. I think the profile just got bad luck where text shadows are what caused the GPU to flush for whatever reason and the GPU has to draw. Sigh GPUs.

Comment 52

[Julien L.]

(In reply to Mason Chang [:mchang] from comment #51)
> All the time spent is within the GPU driver, so I'm not really
> sure what else we can do here. 

So in order to avoid these black glitches, I must set to true the pref "apz.keyboard.enabled"?  Are you sure that anybody could improve your patch? That seems strange to me to see a bug like this unresolved... :/
:)