Bug 75781 – Rounding artifact in SVGTextNode.getBBox()

• Component: SVG
• Status: NEW

[Gene Selkov]

When the user space is transformed to small units, for example, when the entire world is smaller than [0 .. 1], the getBBox() method becomes unusable because it returns integer values (please see the attached test). It is also unusable with larger spaces, say, [0 .. 100], but the effect is less conspicuous.

It works correctly in Mozilla.

The test only demonstrates the effect on a bounding box for a text node, but I suspect the problem is more widespread in Webkit.

The rounding is also apparent in hit-testing. For example, when a set of nodes form a grid spaced 0.5 world units apart, the pointer events fire on all nodes, but only those nodes located at integer grid values are reported as targets of those events. That only happens when the co-ordinates are transformed using the viewBox attribute on the svg root node and does not happen when the transformation is defined as an attribute on a group, but I suspect the culprit is the same or similar. Apparently, parts of the code were only tested in pixel-minded applications.

I can provide a separate test for the viewBox artefact, if that will help.

[Gene Selkov]

Created attachment 121558 [details]
A test for SVGTextNode.getBBox()

[Radar WebKit Bug Importer]

<rdar://problem/10665932>

[Philip Rogers]

I looked into this and it looks like we punt directly through to Skia in this case. The following bug was filed on the Skia side: http://code.google.com/p/skia/issues/detail?id=440

Once that is closed this will most likely be a trivial fix.

[Dominik Röttsches (drott)]

This seems to be the root cause of bug 88772. SVGRootInlineBox::layoutRootBox() rounds to integers. We need higher precision there.

[Nikolas Zimmermann]

(In reply to comment #4)
> This seems to be the root cause of bug 88772. SVGRootInlineBox::layoutRootBox() rounds to integers. We need higher precision there.
This is finally possible by enabling SUBPIXEL_LAYOUT by default for all ports, once that happens, we can finally use non-integer precision in all parts of SVG that interfere with HTML, where currently rounding is needed.
It's on my list :-)

[Gene Selkov]

Please forgive me if I get it all wrong: how can the rounding of user co-ordinates be needed for anything? They have nothing to do with pixels and rendering. They are exactly one transformation away from pixels and sub-pixels, and it is the transformed co-ordinates that I see rounded.

[Dominik Röttsches (drott)]

(In reply to comment #5)
> (In reply to comment #4)
> > This seems to be the root cause of bug 88772. SVGRootInlineBox::layoutRootBox() rounds to integers. We need higher precision there.
> This is finally possible by enabling SUBPIXEL_LAYOUT by default for all ports, once that happens, we can finally use non-integer precision in all parts of SVG that interfere with HTML, where currently rounding is needed.
> It's on my list :-)

If I understood the code correctly even with SUBPIXEL_LAYOUT we'll only get precision to a point of 1/60th fractional increments. For large upscaling from viewbox to viewport we'll still see inaccuracies, right?

[Dominik Röttsches (drott)]

(In reply to comment #6)
> Please forgive me if I get it all wrong: how can the rounding of user co-ordinates be needed for anything? They have nothing to do with pixels and rendering. They are exactly one transformation away from pixels and sub-pixels, and it is the transformed co-ordinates that I see rounded.

As far as my understanding of the code goes: The rounding happens because SVG and HTML text rendering share common code - HTML layout in WebKit traditionally had only integer precision (which is overcome by the SUBPIXEL_LAYOUT changes). So SVG had to map its representations to the integer space of HTML. This happens before the transformation and results in incorrect values after the upscaling.

[Gene Selkov]

I still can't say I see the problem I reported as a layout problem. The thing is, all nodes defined in user co-ordinates are laid out correctly (as far as I can tell). The problem is in going back from the display co-ordinates to user space, which is what getBBox() is supposed to do. It does that approximately correctly when the user space spans many enough whole units that the effects of rounding can be ignored.

Now, imagine a user space defined as [0, 0, 1, 1]. Let's say it is laid out on a display rectangle with these co-ordinates: [50, 50, 250, 250]. I understand you as saying that because of rounding in the display co-ordinates, my user co-ordinates can only be precise to 0.005. I could live with that, but that's not what I see. What I see is the co-ordinates of the bounding box rounded to 0 or 1. I either get a zero-size box or one that spans my entire space.

[Dominik Röttsches (drott)]

(In reply to comment #9)
As I mentioned, it's a problem with bounding box calculation rather than the actual transformations at draw time. At layout time the bounding box is calculated accurately in floats, but then is simplified down to integers. Cmp. SVGRootInlineBox::layoutRootBox() - don't get mislead by the keyword layout in it. It's just that bounding boxes for text objects are calculated during layout phase.

> Now, imagine a user space defined as [0, 0, 1, 1]. Let's say it is laid out on a display rectangle with these co-ordinates: [50, 50, 250, 250]. I understand you as saying that because of rounding in the display co-ordinates, my user co-ordinates can only be precise to 0.005. I could live with that, but that's not what I see. What I see is the co-ordinates of the bounding box rounded to 0 or 1. I either get a zero-size box or one that spans my entire space.

Yep, that's more or less exactly the test case in bug 88772.

[Dominik Röttsches (drott)]

Duplicate of bug 107771?

[Dominik Röttsches (drott)]

Gene, can you retest after r140728, on a port that has subpixel-layout enabled?

[Ahmad Saleem]

Created attachment 460105 [details]
Safari 15.5 matches other browsers

I am not able to reproduce the bug based on attached test case in Safari 15.5 on macOS 12.4. Please refer to attached screenshot for reference. Thanks!

[Alexey Proskuryakov]

This test doesn't work from an attachment any more. It embeds YUI over plain http, and loading that from https is blocked. One needs to download it, and open as a file.

With that, the test still fails:

Expected width = 1.43 and height = 0.09. Returned by getBBox(): width = 1.296875, height = 0.09375

I do not know if that's a bug or expected behavior at this point.

[Ahmad Saleem]

I tried to use YUI 3.5 library from JSFiddle and built this test case - https://jsfiddle.net/rcge4q5f/1/

I can see your expected width issue as well. Thanks!

[Karl Dubost]

With the JSFiddle test. 

I get on <text> element getBBox()
SVGRect {x: -0.453125, y: -0.375, width: 1.296875, height: 0.09375} SAFARI
SVGRect { x: -0.45024996995925903, y: -0.36000001430511475, width: 1.3005000352859497, height: 0.07999999821186066 } FIREFOX
SVGRect {x: -0.43992185592651367, y: -0.3700000047683716, width: 1.2798436880111694, height: 0.08500000089406967} CHROME