Closed Bug 525095 Opened 15 years ago Closed 13 years ago

Artifacts left behind when reducing horizontal scale of text with font-family="sans-serif"

Categories

(Core :: SVG, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: marek.raida, Assigned: longsonr)

References

()

Details

Attachments

(8 files)

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) Reproducible: Always 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 Actual Results: there are artifacts left Expected Results: should be none Reproducible always on my system on given link http://svg.kvalitne.cz/mix/repaint.svg
Attached image original testcase (deleted) —
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... http://svg.kvalitne.cz/mix/repaint.png
Attached image reporter's screenshot (deleted) —
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I today tried it in office on six different computers, two of them running WinVista and problem reproducible on all of them...
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:1.9.1.3) 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)
Here's a screenshot of the no-SMIL testcase, using WinXP Firefox 3.5.3.
Here's a testcase with "bold" removed. It still triggers the bug, though I had to take finer samples to make it noticeable.
Just attaching a screenshot of mozilla-central nightly for this one.
Summary: Text repaint issue in specific conditions → Artifacts left behind when reducing horizontal scale of text with font-family="sans-serif"
Version: unspecified → Trunk
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:1.9.0.16pre) 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.
Attached patch patch (deleted) — Splinter 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.
Assignee: nobody → longsonr
Attachment #587689 - Flags: review?(roc)
Flags: in-testsuite+
Target Milestone: --- → mozilla12
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Blocks: 489877
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: