185778 2018-05-18 12:04:09 -0700 SVG text wiggles when changing its size through animation 2024-01-22 15:26:44 -0800 1 1 1 Unclassified WebKit SVG WebKit Nightly Build Unspecified Unspecified RESOLVED CONFIGURATION CHANGED InRadar P2 Normal --- 1 sabouhallawa webkit-unassigned ahmad.saleem792 bfulgham mail mmaxfield sabouhallawa seb.p.mueller simon.fraser webkit-bug-importer zimmermann oldest_to_newest 1425228 0 340723 sabouhallawa 2018-05-18 12:04:09 -0700 Created attachment 340723 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. 1425230 1 webkit-bug-importer 2018-05-18 12:06:11 -0700 <rdar://problem/40373306> 1426384 2 mmaxfield 2018-05-22 16:33:32 -0700 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. 1426385 3 mmaxfield 2018-05-22 16:35:58 -0700 See also: https://twitter.com/icodewell/status/951225852624297984 1562979 4 seb.p.mueller 2019-08-20 00:43:04 -0700 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. 1563016 5 seb.p.mueller 2019-08-20 02:55:49 -0700 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 1563142 6 simon.fraser 2019-08-20 10:57:15 -0700 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. 1966730 7 ahmad.saleem792 2023-07-14 01:47:27 -0700 @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'? 2006694 8 bfulgham 2024-01-22 15:26:44 -0800 Closing based on Ahmad's testing. 340723 2018-05-18 12:04:09 -0700 2018-05-18 12:04:09 -0700 test case test264.svg image/svg+xml 319 sabouhallawa PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZlcnNpb249IjEuMSI+CiAg ICA8dGV4dCBpZD0iVGV4dEVsZW1lbnQiIHg9IjEwIiB5PSIxMDAiIGZvbnQtZmFtaWx5PSJWZXJk YW5hIiBmb250LXNpemU9IjM1LjI3Ij4gCiAgICAgICAgU29tZSB0ZXh0LgogICAgICAgIDxhbmlt YXRlVHJhbnNmb3JtIGF0dHJpYnV0ZU5hbWU9InRyYW5zZm9ybSIgYXR0cmlidXRlVHlwZT0iWE1M IiB0eXBlPSJzY2FsZSIgZnJvbT0iMSIgdG89IjMiIGFkZGl0aXZlPSJzdW0iIGR1cj0iNnMiIGZp bGw9ImZyZWV6ZSIgLz4KICAgIDwvdGV4dD4KPC9zdmc+Cg==