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

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Marek Raida]

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

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: original testcase

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

Comment 2

[Marek Raida]

I took also screenshot, could be of some use, maybe...

http://svg.kvalitne.cz/mix/repaint.png

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reporter's screenshot

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.)

Comment 4

[Daniel Holbert [:dholbert]]

(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]"

Comment 5

[Daniel Holbert [:dholbert]]

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)

Comment 6

[Marek Raida]

I today tried it in office on six different computers, two of them running WinVista and problem reproducible on all of them...

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: 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: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)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot: no-SMIL testcase, using Firefox 3.5.3

Here's a screenshot of the no-SMIL testcase, using WinXP Firefox 3.5.3.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot: no-SMIL testcase, using mozilla-central nightly

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot: no-bold testcase, on mozilla-central nightly

Just attaching a screenshot of mozilla-central nightly for this one.

Comment 12

[Daniel Holbert [:dholbert]]

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

Comment 13

[Robert Longson [:longsonr]]

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.

Comment 14

[Robert Longson [:longsonr]]

Attachment: patch

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.

Comment 15

[Robert Longson [:longsonr]]

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/04ed59232267

Comment 16

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/04ed59232267