Bug 29696 – [CHROMIUM] Paths fail to render in SVG with large viewbox

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Stephen White]

SVG paths with large coordinate values (and correspondingly large viewbox) are not rendered in Chrome.

See http://crbug.com/21174.

[Stephen White]

Created attachment 40021 [details]
Fix for SVG/skia coordinate issue

[Eric Seidel (no email)]

Comment on attachment 40021 [details]
Fix for SVG/skia coordinate issue

I'm just gonna trust you that this is safe.  The Skia seat-belt is so lame. :(  If you want this committed by the commit-queue you'll need to set commit-queue=?.  I can't remember if you're a committer or not.

[Stephen White]

(In reply to comment #2)
> (From update of attachment 40021 [details])
> I'm just gonna trust you that this is safe.

I ran it by the layout trybots on all three platforms, if that makes you feel better.

> The Skia seat-belt is so lame. :( 

The best solution for that (IMHO) is to write floating point (or even better, SSE2) versions of the pixel loops, so there are no fixed-point limitations to worry about.

[Eric Seidel (no email)]

Comment on attachment 40021 [details]
Fix for SVG/skia coordinate issue

According to http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/committers.py Stephen is not a committer, but it looks like he was invited August 4th.  So I'll assume he just hasn't added himself to that list yet and leave this for him to commit.

[Stephen White]

(In reply to comment #4)
> (From update of attachment 40021 [details])
> According to
> http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/committers.py
> Stephen is not a committer, but it looks like he was invited August 4th.  So
> I'll assume he just hasn't added himself to that list yet and leave this for
> him to commit.

Actually, I did commit it, in the end.. is there something I should do so that appears here?

[Eric Seidel (no email)]

If you committed this bug, than you should update the bug with the revision number that you committed and close it.  Searching the commit logs, I don't see that this has been committed though.

[Roland Steiner]

(In reply to comment #3)
> The best solution for that (IMHO) is to write floating point (or even better,
> SSE2) versions of the pixel loops, so there are no fixed-point limitations to
> worry about.

I agree that this is probably the best interim fix for this bug. 

However, it means that the paths that are not rendered due to my original patch are (potentially) rendered wrong instead. Until the fixed-point implementation in Skia is changed, there doesn't seem to be much that one could do about it, though.

Very minor nit: in currentPathInLocalCoordinates(): one can wait with copying the patch until the matrix inversion has run, in case that fails. Since that's an exceptional case however, there shouldn't be much real impact one way or the other.

[Eric Seidel (no email)]

This was landed as r48726 and can be closed.