1634162 - 3D transformed text blurry and unreadable with webrender

Status: NEW

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

Description

[nemo]

https://m8y.org/tmp/testcase484.xhtml

Had the silly idea of rendering 0.999… similar to the wikipedia svg, but instead of using progressively smaller character styling and separate divs, thought I'd just try positioning and transforming it.

Result in Firefox was hopelessly blurred for no obvious reason.

Chrome rendered it crisply, but oddly has another bug that Firefox has as well (just really hard to make out in firefox due to the blur) where the digits are swapped further down the line.

I made https://m8y.org/tmp/testcase485.xhtml where the 9s are replaced with Es to make this more obvious.

Comment 1

[Timothy Nikkel (:tnikkel)]

I see the blur with webrender but not without. Are you using webrender?

Comment 2

[Timothy Nikkel (:tnikkel)]

regression range
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b93db4865f2996b8e05e3b8e618a090942ee449&tochange=12389e959ebb20da037a8800c2797b871afd29ea

-> bug 1613260

Comment 3

[nemo]

I am indeed! We were wondering about that in freenode #firefox (irc://irc.freenode.net/firefox), but yesterday was pretty busy so forgot to follow up in bug.

Comment 4

[nemo]

I was getting it in Webrender on linux, Caspy7 in windows.
I assume that's just the blurriness and not the text flipping.

Comment 5

[Bert Peers [:bpeers]]

Attachment: text_compare.png

Thanks nemo for the great description and repro steps! Also thanks Timothy for finding the regression range.

The digit flipping is just aliasing, there's not much we can do about that -- it's similar to the effect in movies where an accelerating car will have the wheels stop and then spin backwards.

The blurring is more serious. In this test case we create a surface that's 142000 x 200 pixels (depends on browser width + DPI setting). If we try to render this on the GPU directly we can only do 8000 pixels at most so there's a 17x magnification.

The old code that establishes a raster root doesn't have this problem.
Side note, non-Webrender is kind of halfway -- it blurs horizontally.

Going back to raster roots brings back the issues of 1. having to rasterize SWGL text with perspective, 2. applying filters in the wrong order, and 3. not being able to cache all pictures. I'm not sure where we are with #1 especially so I'll ping Lee and Glenn on what we could do about this.

Comment 6

[Glenn Watson [:gw]]

This is all speculation, I haven't looked at it in detail yet.

I think we can probably get acceptable quality in this case (the same or better than regular Gecko) while retaining the local-space rasterization, with some tweaks to how we draw it.

The first thing I'd look into is why we were looking to create a surface that is 142000 pixels wide - that seems wider than I'd expect, given the test case.

I'd also look into what size glyph we're selecting to rasterize the surface with, and whether that's based on any local scale suggestion by Gecko in the requested raster space, or if we're determining it automatically.

My guess to what's happening: we're selecting a large glyph size in pixels, trying to get good quality rendering for the first few glyphs. This has a knock-on effect of making the natural width of the surface extremely wide, which we then scale down a huge amount due to the surface requirements.

It seems possible that if this is occurring, we would get better quality in this case by selecting a smaller glyph size - I think this would give a similar result as normal Firefox.

Does that sound plausible?

Comment 7

[Timothy Nikkel (:tnikkel)]

(In reply to Bert Peers [:bpeers] from comment #5)

Side note, non-Webrender is kind of halfway -- it blurs horizontally.

FWIW, my non-wr rendering is much crisper than your screenshot (on mac). It's not as crisp as the establish render root case in your screenshot though.

Comment 8

[Bert Peers [:bpeers]]

Thanks for the comments.
Taking a quick look at a wr-capture, there's this font in the interners. Each 'E' takes up ~123 pixels horizontally and there's a 1000 of them. The source sets font-size to 10% of viewport width, which would be ~120 pixels (~1800 / 150%DPI * 10%) (I'm just guessing how layout works).

Would that mean we'll never have more than 8 pixels per E?
Is chopping up long text-runs in layout an idea?

common: (
    flags: (
        bits: 1,
    ),
    prim_rect: (
        x: 7.770833492279053,
        y: -10.208333015441895,
        w: 123220.5859375,
        h: 181,
    ),
),
font: (
    base: (
        instance_key: ((3), 4),
        font_key: ((3), 3),
        size: 9635,

// ...
glyphs: ([
    (
        index: 40,
        point: (-7.770833492279053, 146.2083282470703),
    ),// [0]
    (
        index: 40,
        point: (115.39582824707031, 146.2083282470703),
    ),// [1]

Comment 9

[Lee Salzman [:lsalzman]]

I tried to investigate this a little, and inside TextRunPrimitive::update_font_instance, it looks like the addition of root_scaling_factor is somewhat interacting badly with this testcase. The rotateY transform, as it becomes more extreme towards 45 degrees, seems to cause root_scaling_factor to go towards 0.01739... This then gets recorded in the FontTransform via glyph_raster_scale (which incorporates root_scaling_factor), which the font backend sees as a request to render the font at a very very small resolution (about 5px).

Given that originated in bug 1613260, and I am not sure exactly how root_scaling_factor is derived, Bert, is there anything we can do to mitigate that part?

Comment 10

[Bert Peers [:bpeers]]

Thanks for confirming Lee.
The small font size is due to trying to fit a 140,000 pixel wide surface into a 8192-wide rendertarget.
The perspective transform is forcing the text into an off screen surface, and the 1000 glyphs at a large font size result in a large surface.
There is no obvious fix for this since everything is "visible" -- we cannot be smart and clip invisible chunks of text to get that 140000 number down.

The old code did not have this problem because it would rasterize directly into screen space, ie. the glyphs are rasterized directly with a perspective transform (AFAIK). This avoids the issue but then requires support for such rendering in SWGL. It would also be the wrong order of operations in some cases (eg. incorrectly blurring in screenspace after the perspective).

That's my understanding so far, I don't have a solution :\

Comment 11

[nemo]

BTW, I don't know if this adds any information, but this was the wikipedia SVG I was talking about:
https://upload.wikimedia.org/wikipedia/commons/a/ae/999_Perspective.svg
off of
https://en.wikipedia.org/wiki/0.999...

That I decided to try a quick CSS simulation of.
What's curious to me is that while the SVG seems to have a heck of a lot of digits (assuming each m in the paths is a new digit, 411+184*5 = 1331 ) it does render cleanly in firefox with webrender.
Admittedly the digits are paths and not actual font, but should that matter?

Anyway, figured I'd link it just in case it offers any context.

Comment 12

[nemo]

Er... 411+184*8 = 1883 - sorry. missed a few paths when counting 'em.

Comment 13

[nemo]

Minor update. Was supporting someone with a similar issue and linked to this testcase as a dramatic explanation.
I was surprised that the blurring at worsened.
https://m8y.org/tmp/testcase484.xhtml It used to be that this was a severely out of focus image where you could just barely make out the general shape of the digits. Now it is nothing but a series of blobs of uniform height, as if the transform is broken as well.

Comment 14

[Mayank Bansal]

The text is blurred when I open the page. However, it becomes crisp if I pinch-zoom.

This seems very similar to bug 1792390.

Comment 15

[Mayank Bansal]

Attachment: Blur text becomes crisp on pinch-zooming.mp4

Comment 16

[nemo]

Not entirely surprising to me if the issue was some max texture allocation size.
As noted in comment #10 4 years ago
"The small font size is due to trying to fit a 140,000 pixel wide surface into a 8192-wide rendertarget."

So, when you zoom I'm guessing you get to a small enough portion of it that it can render in 8192 bytes. I'm guessing zooming out still breaks.

I mean, obviously it is possible to render something like this cleanly :) it's just clearly the generic transform approach is hitting an edgecase here...

Honestly I didn't need a fix. I was just reporting the issue in case anyone else encountered it, and in case there was a fairly simple solution.

Hm. Although I see in my comment #13 that someone had a real world issue with blurry transforms. I don't recall what it was at the time. So maybe this could be considered a stress test 😉