|Summary:||SVG text wiggles when changing its size through animation|
|Product:||WebKit||Reporter:||Said Abou-Hallawa <sabouhallawa>|
|Severity:||Normal||CC:||mail, mmaxfield, sabouhallawa, seb.p.mueller, simon.fraser, webkit-bug-importer, zimmermann|
|Version:||WebKit Nightly Build|
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 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
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.