User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Repaint problems when using some sans-serif font (Arial, Helvetica) in bold weight and shrinking/transforming text from right to left.
Problem is not there with all fonts, only some, and never in normal weight.
It is visible on large texts (starts with font-size over 100px, the bigger the problem more visible)
Steps to Reproduce:
1. Create text element, with font-family="Helvetica", font-weight="bold" and font-size="120px"
2. encapsulate text element to group and apply to group animateTransform, scale, from something big (like 2) to something small (like 0.5)
3. on the direction from right to left, some fonts are not repainted/cleared correctly
there are artifacts left
should be none
Reproducible always on my system on given link http://svg.kvalitne.cz/mix/repaint.svg
Created attachment 408951 [details]
Here a copy of the reporter's testcase for Bugzilla.
FWIW, I can't currently reproduce, using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre
I took also screenshot, could be of some use, maybe...
Created attachment 408963 [details]
Attaching the screenshot here. (It's best to testcases/screenshots directly to the bug, rather than posting them elsewhere. That way, if someone takes a look at this bug in 6 months or a few years, they'll still be able to see what was broken, even if you've modified / moved / removed the file on your own server.)
(In reply to comment #3)
> Attaching the screenshot here. (It's best to testcases/screenshots directly to
> the bug, rather than posting them elsewhere.
Sorry -- "It's best to _attach_ testcases/screenshots [etc]"
Confirmed on WinXP (I see behavior matching what's captured in the screenshot above).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)
I today tried it in office on six different computers, two of them running WinVista and problem reproducible on all of them...
Created attachment 409203 [details]
no-SMIL testcase (using JS for animation)
Here's a simple, no-SMIL testcase that just tweaks the 'transform' attribute at periodic intervals. On Windows XP, I get tons of artifacts left over by the 'A' character, and a few left over by the 'V' character. Tested a mozilla-central nightly as well as Firefox 3.5.3. (both are affected, though mozilla-central nightly is marginally better):
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091029 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Created attachment 409204 [details]
screenshot: no-SMIL testcase, using Firefox 3.5.3
Here's a screenshot of the no-SMIL testcase, using WinXP Firefox 3.5.3.
Created attachment 409205 [details]
screenshot: no-SMIL testcase, using mozilla-central nightly
Created attachment 409206 [details]
no-bold testcase (Using JS for animation)
Here's a testcase with "bold" removed. It still triggers the bug, though I had to take finer samples to make it noticeable.
Created attachment 409207 [details]
screenshot: no-bold testcase, on mozilla-central nightly
Just attaching a screenshot of mozilla-central nightly for this one.
FWIW: This is not a regression since 3.0. I can reproduce this with latest 3.0.x nightly (tried both "no-SMIL" and "no-bold" testcases)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/2009110206 GranParadiso/3.0.16pre
Unfortunately these characters stick out of the glyph cell for the font and we invalidate based on the glyph cell rather than the actual bounds of the character.
Determining the actual bounds is more expensive.
Early patches for bug 520506 contained a fix for this issue by nsSVGGlyphFrame::UpdateCoveredRegion from using AddBoundingBoxesToPath to using AddCharactersToPath not sure what else can be done really.
Note that the final patch for bug 520506 did not contain that change though.
Created attachment 587689 [details] [diff] [review]
If you've looked at the patch in bug 616892 you've already seen this fix embedded in that patch. I'm struggling to land the patch for bug 616892 though as it causes a single reftest failure on Linux. Fortunately this bit can land on its own and fix this bug.