Bug 185778 - SVG text wiggles when changing its size through animation
Summary: SVG text wiggles when changing its size through animation
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-18 12:04 PDT by Said Abou-Hallawa
Modified: 2024-01-22 15:26 PST (History)
9 users (show)

See Also:


Attachments
test case (319 bytes, image/svg+xml)
2018-05-18 12:04 PDT, Said Abou-Hallawa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Said Abou-Hallawa 2018-05-18 12:04:09 PDT
Created attachment 340723 [details]
test case

Open the attached test case.

Result: The text wiggles while it is animating. The inter-character spacing keep incrementing and decrementing slightly while the animation is progressed.
Expected: The inter-character spacing increments only when scaling up the size of the text.
Comment 1 Radar WebKit Bug Importer 2018-05-18 12:06:11 PDT
<rdar://problem/40373306>
Comment 2 Myles C. Maxfield 2018-05-22 16:33:32 PDT
We have a lot of dups of this. It’s because we quantize the sub pixel position of glyphs to increase our CoreGraphics glyph cache hit rate. Every time we stop quantizing we always get a huge regression.

None of the other browsers do this quantization.
Comment 3 Myles C. Maxfield 2018-05-22 16:35:58 PDT
See also: https://twitter.com/icodewell/status/951225852624297984
Comment 4 Sebastian Müller 2019-08-20 00:43:04 PDT
This is really ugly and bugs many of our enterprise customers of our commercial visualization library. We are forced to either tell them to render text in pixelated Canvas images or tell them to go and use a better (in this respect) browser.

I understand the problem, but I do think there should be a relatively simple solution to this problem that cannot be that performance critical. I haven't looked at the sources of other engines, but I closely inspected their rendering and I guess they are using the same optimized strategy: In order to get rid of the "wiggling"/jumping/dancing characters, it's not so important to quantize the font sizes to subpixels. As you can see in Chrome, they are also quantizing the font size of each single glyph. However they are calculating the exact accumulated position of each character in a long string. This approach should not affect the glyph cache hit rate because you can use the same cache entry at different zoom levels. All you need to do is use pixel exact glyph positioning. "sub pixel" isn't even necessary, as current the glyphs jumps around dozens of pixels on the screen so the error is at least 20 screen pixels in many situations and bringing that error down to 1px would be a *huge* improvement.
Comment 5 Sebastian Müller 2019-08-20 02:55:49 PDT
I just saw that the test case attached to this issue does not really look as bad as it does in my test case.

See this test for a much severe effect:

Pan the text into the view by dragging the mouse/touchpad - preferrably near the end of the text.

Then slowly zoom into the SVG using two finger drag. Observe that the text wiggles and dances wildly and characters jump around up to several dozen pixels.

https://jsfiddle.net/Lrhadotp/show
Comment 6 Simon Fraser (smfr) 2019-08-20 10:57:15 PDT
I don't think this is about sub pixel quantization, I think it's about internal font sizes or something.

We also have the option of turning off quantization in various circumstances, which we do already.
Comment 7 Ahmad Saleem 2023-07-14 01:47:27 PDT
@Myles - I think your fractional font sizes PR has fixed this because I am not able to reproduce this in WebKit ToT (266059@main).

We can mark this as 'DUPLICATE' or 'CONFIGURATION CHANGED'?
Comment 8 Brent Fulgham 2024-01-22 15:26:44 PST
Closing based on Ahmad's testing.