703873 - SVG in img tag very slow to drag compared to png as background

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[jonesr]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

I have a chess board implementation where pieces are moved around via drag and drop (implemented using YUI3's drag and drop abstraction).

I have two implementation of the board pieces, one uses an SVG in an <img>tag, the other uses a div with background image using a png for browsers which don't support SVG in <img> tags.

I've found that the SVG image tags are MUCH slower to drag around than the pieces based on background images on Firefox compared to Chrome and Safari.

You can see the svg pieces in action here:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=1

and the png background based images here:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=0

Drag the pieces around on each page and compare the lag on the SVG version to the PNG version.

I would have thought the SVG has been well and truly rasterised at the point of dragging, so perhaps SVG has nothing to do with the problem, and the issue is <img> versus background, but that would also seem odd.


Actual results:

SVG piece dragging is very slow (piece lags well behind mouse pointer).
PNG background image piece dragging is relatively fast.

Chrome and Safari are fast on both examples, with almost no noticeable lag.


Expected results:

Both examples would ideally perform the same (which is what they do on latest release Chrome/Safari).

Comment 1

[Mardeg]

Attachment: Short zoom and pan demo of SVG in <img> still being vectors

(In reply to jonesr from comment #0)
> I would have thought the SVG has been well and truly rasterised at the point
> of dragging, so perhaps SVG has nothing to do with the problem
From this demo we still see crisp edges meaning the SVG hasn't been rasterised then enlarged.

Comment 2

[Mardeg]

I forgot to mention that the attached demo when run in webkit browsers shows from the non-crisp edges that they DO rasterise SVG, so that would explain how dragging them is the same speed as dragging the PNG images in webkit.

Comment 3

[jonesr]

(In reply to Mardeg from comment #2)
> I forgot to mention that the attached demo when run in webkit browsers shows
> from the non-crisp edges that they DO rasterise SVG, so that would explain
> how dragging them is the same speed as dragging the PNG images in webkit.

Is it possible this is platform dependent rendering? I'm seeing the same crisp edges on mac os X under firefox, google chrome and safari. When I said "I would have thought the SVG has been well and truly rasterised at the point of dragging" I meant I assume the bitmap has been created to display the piece at the current zoom level before dragging occurs, and that re-rasterisation shouldn't be occurring as the piece is being moved around the screen. Does your attached test case indicate that the SVG is being re-rasterised each time its x,y position changes on the screen? Keeping the underlying entity as SVG seems like the right thing to do, and in fact I rely upon it, as one of the benefits of using SVG for the piece images is that they re-size nicely when I drag the board to larger sizes (using the resize handles to the right of the board), as they are in containers that auto resize as the width/height of the container increases (for png's I require an annoying hack to swap in CSS that uses different sized png's after changes in the board size). At least on the mac, the pieces are being properly resized (i.e. smooth at all zoom levels) across firefox/chrome/safari, so they are at least keeping some connection with the underlying svg inside the img tag.  I'll need to test my own code on windows under the webkit browsers, to make sure I'm getting the same zoom effect I'm seeing under Mac OS X.

In any case it seems webkit on the mac is making a useful optimisation here that would be handy to have done on Firefox across all platforms.

Comment 4

[Mardeg]

Keep an eye on when bug 524925 and bug 629200 land on trunk to retest. Hopefully it'll be before the next bump to Firefox 12 in which case the build link will be:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-11.0a1.en-US.mac.dmg

Comment 5

[jonesr]

Thanks mardeg, I'll keep an eye on those.

Comment 6

[jonesr]

The svg dragging is still very slow in Firefox 14 (which I assume includes the work mentioned in bug 524925 and 629200.

I also notice I mixed up the links to test cases in my original comment, the png case and the svg case were swapped , the SVG should have been:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=0

and the faster (but still slow compared to webkit) PNG case was:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=1

Apologies for any confusion with the test cases.

Comment 7

[Jonathan Watt [:jwatt]]

Prior to bug 157681 we were reflowing, invalidating and repainting the entire chessboard when a piece moved. Bug 157681 fixed that and seems to have completely fixed this bug to me. That fix will first ship in Firefox 16.

jonesr: If you care to download the latest nightly build and confirm dragging now works for you the link is:

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Comment 8

[jonesr]

Thanks Jonathan,

That does indeed appear to have fixed the performance issue with the SVG version, and the PNG version might also be quicker now, but it seems to have created a new problem, when I use the SVG via this link:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=0

When the pieces are dragged over the other SVG pieces, they erase parts of the SVG images they move over, as if they are an 'eraser' widget in a drawing tool. The pieces re-appear once the drag has finished, so I suspect some kind of repainting that bugfix 157681 avoids is actually required in this case (and is being done once the drag finishes). 

Should I file another bug, or is this a known problem with the nightly?

I'm running this under mac os X 10.6.8 if that makes any difference.  Does that web page produce the same result for you?

Regards,
Richard.

Comment 9

[Jonathan Watt [:jwatt]]

It was actually a much later bug that caused that "eraser" problem, but I _just_ landed a fix for that yesterday. That fix does seem to be in "16.0a1 (2012-06-06)" since I can't reproduce the problem using that build. Can you check "Nightly > About Nightly" and check whether you have "16.0a1 (2012-06-06)" or some other version?

Comment 10

[Jonathan Watt [:jwatt]]

Huh! So it seems that latest-mozilla-central directory than I linked you to has both firefox-16.0a1.en-US.mac.dmg and firefox-17.0a1.en-US.mac.dmg in it. You need the firefox-17.0a1.en-US.mac.dmg build to get the latest one. I've no idea why the 16.0 build is in there, but that's two days out of date.

Comment 11

[jonesr]

Thanks,

I tried 17.0a1, and it still seemed to have the 'erase' effect.

So I'm seeing the eraser effect on both these nightly builds:
16.0a1 (2012-07-16)  
17.0a1 (2012-07-18)

Is it possible the 17.0a1 doesn't have your latest fix yet?

Regards,
Richard.

Comment 12

[Jonathan Watt [:jwatt]]

Weird. I can reproduce the bug very easily in the former build, but absolutely not at all in the latter. Can you open your 17.0a1 (2012-07-18) build, double check that you can reproduce the "erasor" problem, load the page "about:support", and paste the "User Agent" line? (Something like "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/16.0 Firefox/16.0a1".)

Comment 13

[jonesr]

Yup,

I go here:
http://chesstempo.com/pgn-viewer-beta.html?nosvg=0

Then grab one of the white chess pieces (say the knight), and drag it over the other pieces on the board, and it erases as it goes. The actual "erasing" is a little strange, you can completely erase another piece, then drag over where the piece was and it 'repaints' the piece.

My about:support output for version and user agent is:
            
              Version: 17.0a1

              User Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Firefox/17.0

I'll try again with a fresh profile with no extensions etc loaded, and see if it still reproduces the problem.

Comment 14

[jonesr]

Using a fresh profile with the 17.0a1 nightly was still able to reproduce the problem (although the default profile chose a slightly smaller window size which changed the layout slightly, and the pieces may have been a little less 'erasable' than with my wider than default window sizing (but definitely still there).

Comment 15

[Jonathan Watt [:jwatt]]

Okay, I think the problem with reproducing is on my side. I'll file a new bug and CC you on it and we can discuss it further there.

Comment 16

[Jonathan Watt [:jwatt]]

Filed bug 775136.

Comment 17

[jonesr]

This performance issue still exists in the 17.0.1 release (at least on Mac OS X 10.8.2). Apart from the bug Jonathan fixed with bug #775136, the performance issue appeared to have been resolved in the test builds he directed me to at the time. Is the current performance issue (which you can reproduce using the same steps described in my original report), a regression, or did the performance improvements not eventually make it to the 17.0.1 final release?

Comment 18

[jonesr]

Ok, I did some digging and it seems the performance fix in bug #157681 was backed out due to bug #775350. I wasn't clear from the discussions on 775350 if the performance changes in 157681 were going to come back or not, or if that has been put in the 'too hard' basket for now?

Comment 19

[Matthias Versen [:Matti]]

Reporter: Is this now resolved with Firefox19 ?

Comment 20

[jonesr]

Looks fixed to me under Firefox19, the SVG and PNG pieces now appear to drag at the same speed (or close enough for any performance not to be noticeable).

Thanks for whoever is responsible for fixing this!

Regards,
Richard.

Comment 21

[Matthias Versen [:Matti]]

Great !