1228112 - [e10s] Garbled text while scrolling

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[heuripedes]

Attachment: garbled-text-scroll-issue.webm

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151123030237

Steps to reproduce:

1. Open any website, e.g. a blog
2. Scroll down a bit


Actual results:

Text becomes nearly unreadable in certain areas.


Expected results:

Text should have been rendered properly.

Comment 1

[heuripedes]

Attachment: Troubleshooting Info

Comment 2

[heuripedes]

Attachment: Garbled text in Troubleshooting Information after scrolling

Comment 3

[Michelle Funches - QA]

@Reporter: I am not seeing this behavior in the 11/23/2015 version or the updated nightly version > 
20151201030226
Mozilla/5.0(X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0)
I access Troubleshooting Information and scroll both ways - are there additional steps I can apply? Are you still seeing this behavior? Have you applied the Nightly updates?

Comment 4

[heuripedes]

Just updated to 20151205030208 and it still happens. Try going until the end of the page and then going back to the top. I'm using the scroll wheel to scroll the page, if it matters.
One thing has changed since I reported the bug: if I switch to a different tab and come back, the issue is gone, but scrolling again makes it come back eventually.

Comment 5

[heuripedes]

Attachment: Scrolling Troubleshooting Information.webm

Comment 6

[heuripedes]

Seems to happen if I use the scroll bar or arrow keys too.

Comment 7

[Michelle Funches - QA]

I am unable to reproduce, setting the ticket to Re-open and New
 	20151214030220
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Comment 8

[Tracy Walker [:tracy]]

Please try to reproduce in safe mode to rule out the possibility tat one of your extensions is involved in this bug.  Thanks.

Comment 9

[heuripedes]

Using 20151228030213 now.
Tried safe mode and refreshing my install but the issue was still there.
After disabling hardware acceleration I noticed troubleshooting information listed layers.acceleration.disabled as changed so I searched for "layers" in about:config and tried a few settings.
Disabling layers.async-pan-zoom.enabled and restarting the program seems to solve the issue for me.

Comment 10

[heuripedes]

Attachment: Troubleshooting Info 2015-12-28

Comment 11

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

Markus, any thoughts? Based on comment 6 and comment 9 it's probably something enabled by APZ in layout.

Comment 12

[Timothy Nikkel (:tnikkel)]

Hmmm, that's odd. Maybe the displayport is large enough to trigger the max texture size check here

http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp?rev=058b21faea53#5182

and the max texture size on this system is smaller than usual? We could try temporarily modifying a pref on this system to make the displayport much smaller.

Comment 13

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

It's possible, I guess, but I would have expected the problem to happen as soon as the scrolling down started after page load, because that's when the displayport expands. It shouldn't really change in size at the point shown in the video, where the user is just scrolling back up a bit.

But it's worth a shot to see what happens - heuripedes, can you try setting:
layers.async-pan-zoom.enabled -> true
apz.x_skate_size_multiplier -> 0.0
apz.y_skate_size_multiplier -> 0.0
apz.x_stationary_size_multiplier -> 0.0
apz.y_stationary_size_multiplier -> 0.0

restart the browser, and see if the problem still happens? Thanks!

Comment 14

[Markus Stange [:mstange]]

I think the loss of resolution happens during compositing, here using BasicCompositor with cairo using xrender.
There are two pieces of evidence towards that in the video: First, it shows that the problem goes away for a small part of the page that is invalidated during text selection. Then, the redrawn part of the page is scrolled slightly out of view and back into view, and it's back to low resolution.

Text selection on that page ( http://eslint.org/docs/user-guide/configuring.html ) does not affect layerization, so all we're doing is invalidating, repainting and partial re-compositing of a small part of a PaintedLayer. During the scrolling at the end, the newly-drawn text stays in the display port and is not invalidated.
This means that:
 (1) The problem is not caused by a scale we're setting on a ContainerLayer because that would affect the whole layer, and
 (2) The whole PaintedLayer contents are probably full resolution.

So for some reason, if we do a full composition of the window, the layer gets drawn at low resolution, but if we only composite small parts of the window, it's drawn at full resolution.

It's not clear to me why this happens. I agree that it's probably caused by a large layer size, so decreasing the size of the display port should fix it. Xrender might be hitting some (useless?) limit when drawing part of a large surface into a large part of the window, but not when drawing a smaller part of a large surface into a smaller part of the window.

Comment 15

[heuripedes]

(In reply to Timothy Nikkel (:tn) from comment #12)
> Hmmm, that's odd. Maybe the displayport is large enough to trigger the max
> texture size check here
> 
> http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.
> cpp?rev=058b21faea53#5182
> 
> and the max texture size on this system is smaller than usual? We could try
> temporarily modifying a pref on this system to make the displayport much
> smaller.

I don't know what's the "usual" but this is an old computer so probably yes. I'll attach the output of `glxinfo -l`, but here's some texture related information:
>    GL_MAX_TEXTURE_SIZE = 2048
>    GL_MAX_3D_TEXTURE_SIZE = 256
>    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 2048
>    GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 2048
>    GL_MAX_TEXTURE_UNITS_ARB = 8
>    GL_MAX_TEXTURE_LOD_BIAS_EXT = 14
>    GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 4
>    GL_NUM_COMPRESSED_TEXTURE_FORMATS = 5

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #13)
> It's possible, I guess, but I would have expected the problem to happen as
> soon as the scrolling down started after page load, because that's when the
> displayport expands. It shouldn't really change in size at the point shown
> in the video, where the user is just scrolling back up a bit.
> 
> But it's worth a shot to see what happens - heuripedes, can you try setting:
> layers.async-pan-zoom.enabled -> true
> apz.x_skate_size_multiplier -> 0.0
> apz.y_skate_size_multiplier -> 0.0
> apz.x_stationary_size_multiplier -> 0.0
> apz.y_stationary_size_multiplier -> 0.0
> 
> restart the browser, and see if the problem still happens? Thanks!

Can't reproduce the issue after your suggestions.

Comment 16

[heuripedes]

Attachment: glxinfo -l

Comment 17

[heuripedes]

Noticed that while
> layers.async-pan-zoom.enabled -> true
> apz.x_skate_size_multiplier -> 0.0
> apz.y_skate_size_multiplier -> 0.0
> apz.x_stationary_size_multiplier -> 0.0
> apz.y_stationary_size_multiplier -> 0.0
fixes the text issue, it seems to introduce some black bars at the top and bottom of the screen while scrolling some pages like Github code listings

Comment 18

[heuripedes]

Attachment: Scrolling black bars.webm

Comment 19

[Michelle Funches - QA]

A little quirky: no loss of functinality or garbled text.
Firefox
47.0a1
20160201030241
Mozilla/5.0 (X11;Linux i686;rv:47.0) Gecko/20100101 Firefox/47.0
 - Pref Check is:
> layers.async-pan-zoom.enabled -> true
> apz.x_skate_size_multiplier -> 2.5
> apz.y_skate_size_multiplier -> 3.5
> apz.x_stationary_size_multiplier -> 3.0
> apz.y_stationary_size_multiplier -> 3.5

Comment 20

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

The black bars (comment 18) is an expected result of the pref change, because the displayport is not extending beyond the edge of the visible area.

Anyway based on comment 14 this belongs in the gfx component.