1559861 - Fuzzy text on office.com with apz.allow_zooming enabled (3d transforms cause fuzzy text, webrender version)

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Asif Youssuff]

Attachment: Screenshot from 2019-06-17 23-09-20.png

1. enable apz.allow_zooming;true
2. navigate to https://www.office.com/
3. pinch to zoom

What happens:

The text "Welcome to Office Your place to create, communicate, collaborate, and get great work done." is fuzzy.

Expected result:

Sharp text.

Comment 1

[Asif Youssuff]

Attachment: wr-support

Comment 2

[Botond Ballo [:botond]]

Please mention what platform this is on. Thanks!

Comment 3

[Asif Youssuff]

I'm on Linux.

Comment 4

[Asif Youssuff]

FYI this is also reproducible on macOS.

Comment 5

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

I'm not able to reproduce this on macOS on the latest nightly, with or without WebRender. Can you recheck?

Comment 6

[Asif Youssuff]

Kats, try https://web.archive.org/web/20200101011105/https://www.office.com/ - the page has changed since I reported the bug.

I can still reproduce it on macOS and Linux.

Comment 7

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

Thanks, I can repro on the archive.org link as well.

Comment 8

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

This appears to be coming from the transform-style: preserve-3d style on the enclosing <div class="home__container">. The current version of office.com doesn't have this style and zooming in keeps things sharp. If I remove this style from the archive.org version it also works fine. Presumably this style is changing our layer tree structure somehow to rasterize at a lower resolution than what we would like.

The interesting thing is that it happens with both WR on and off, at least in my testing. The two should be using pretty different codepaths in this respect, but maybe they use the same ChooseScaleAndSetTransform code and that might be the culprit. Not sure, needs more investigation.

Comment 9

[Timothy Nikkel (:tnikkel)]

Attachment: reduced testcase

Comment 10

[Timothy Nikkel (:tnikkel)]

The reduced testcase and the archive.org link both show the fuzzy text on fenix on android (it doesn't render well enough to check on fennec). The reduced testcase has fuzzy text on fennec and fenix. So not unique to desktop zooming.

Comment 11

[Timothy Nikkel (:tnikkel)]

Attachment: testcase using transform, no zooming required

You can get the same effect with just a transform, no need for zooming.

Comment 12

[Connor Brewster [:cbrewster]]

Attachment: Bug 1559861: WR - Scale picture tasks based on their surface to parent transform scale factors r=gw,Bert

This patch adjusts the device pixel scale for raster root surfaces so that the surface's content is not
pixelated/blurred when it is composited into its parent surface where a transform scales up the surface.

This only fixes the referenced bug when WebRender is used.

Comment 13

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

(In reply to Connor Brewster [:cbrewster] from comment #12)

This only fixes the referenced bug when WebRender is used.

Do you have any plans to fix or investigate the non-WebRender version of this bug?

Comment 14

[Connor Brewster [:cbrewster]]

I'm not nearly as familiar with the non-WR rendering path, but I did a little bit of digging and I think this would be fixed by handling the 3D transform case in FrameLayerBuilder::ChooseScale. (https://searchfox.org/mozilla-central/rev/9f074fab9bf905fad62e7cc32faf121195f4ba46/layout/painting/FrameLayerBuilder.cpp#6030)

I'm happy to work on a fix for the non-WR path, but I may need some guidance.

Comment 15

[Timothy Nikkel (:tnikkel)]

I have a fix for the non-wr bug.

More or less this

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4aa5e23d53a03b8fd96ebba26a7ecac528ec30bc

but I'm holding off because I have more important fixes to ChooseScale stuff to land first (ie regression fixes) before making an improvement fix that could cause regressions.

Comment 16

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

Great, thank you both!

Comment 17

[Timothy Nikkel (:tnikkel)]

I think that the non-wr side of this should be split off into a separate bug so it can land separately and just make this bug about wr.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/41acfa78dae4
WR - Scale picture tasks based on their surface to parent transform scale factors r=gw,Bert

Comment 19

[Dorel Luca [:dluca]]

Backed out changeset 41acfa78dae4 (bug 1559861) for Wrench failure in transforms/raster-root-scaling.yaml

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=303025012&repo=autoland&lineNumber=1459

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=41acfa78dae455503214f4beb23d75ac1995332b

Backout:
https://hg.mozilla.org/integration/autoland/rev/fc29fa01d6aa9652a4d83960fccd52ef98a45f32

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a94271c84318
WR - Scale picture tasks based on their surface to parent transform scale factors r=gw,Bert

Comment 21

[Timothy Nikkel (:tnikkel)]

Filed bug 1639764 for the non-wr case as well as for webrender content that uses a scale from ChooseScale.

Comment 22

[Noemi Erli[:noemi_erli]]

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