319990 - The mouseover event is extremely slow.

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Sean]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Firefox 1.5

The mouseover event is extremely slow compared to the identical svg file in IE with asv.  Compare to http://www.seanmontague.com/test.html.

Same svg and same javascript.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.seanmontague.com/test.xml
2.
3.

Actual Results:  
Very slow.

Expected Results:  
Fast.

IE with asv works better.  Will not be able to develop in FF 1.5.

Comment 1

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 ID:2005111116
I see slow mouseover too.

Comment 2

[Steve England [:stevee]]

Can't attach testcase from URL because bugzilla limits such attachments to 300k

Comment 3

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051211 Firefox/1.5

It only reacts to mouseover when I stay at least one second on the image (or click on it). But then it takes another 2 or 3 seconds before the image turns yellow.

Comment 4

[Sean]

I accidently deleted the svg file.  It is back up.

Comment 5

[Alex Vincent [:WeirdAl]]

There's a bug in the testcase.

Error: Expected color but found 'stroke'.  Error in parsing value for property 'fill'.  Declaration dropped.
Source File: http://www.seanmontague.com/test.xml
Line: 0

onmouseout="out2('10','Point','stroke')"

function out2(id,type,what) {
  svgobj.setAttributeNS(null, 'fill', what);
}

I also note the path is very, very long...

Comment 6

[Sean]

I'm not sure what to do to correct that particular bug. I updated it with the code below. The path being long to me is moot point given that IE and ASV have no problem with it. They are the standard for what I expect performance wise. As long as that is an issue, I cannot develop with FF in mind.

function over2(id) {               
  svgobj=document.getElementById(id);
  svgobj.setAttributeNS(null, 'fill', 'yellow');
}
function out2(id,what) {
  svgobj.setAttributeNS(null, 'fill', what);
}

<g id="Americas" fill="rgb(183,223,134)">
  <path id="10" onmouseover="over2('10')" onmouseout="out2('10',1)" d="z"/>
</g>

Comment 7

[Robert Longson [:longsonr]]

The example has disappeared again. Is this the same issue as bug 404963? Are you using complex paths and do you need pointer-events set to visiblePainted (the default)?

Comment 8

[Sean]

Thanks. They're back up. I'm not using a complex path, just d="M 830818 -1078590 L 828673 -1079445 L 827246 -1083714... It's rather long.

I'm not sure what you mean by the visiblePainted. As far as being the same issue as 404963, could be, I tried the examples, and things seemed quick.

Comment 9

[Sean]

I just tried it in FF3 Beta 5, while it is much faster, still not as fast as IE ASV or Safari Beta Win.

(In reply to comment #8)
> Thanks. They're back up. I'm not using a complex path, just d="M 830818
> -1078590 L 828673 -1079445 L 827246 -1083714... It's rather long.
> 
> I'm not sure what you mean by the visiblePainted. As far as being the same
> issue as 404963, could be, I tried the examples, and things seemed quick.
> 

Comment 10

[Robert Longson [:longsonr]]

(In reply to comment #8)
> Thanks. They're back up. I'm not using a complex path, just d="M 830818
> -1078590 L 828673 -1079445 L 827246 -1083714... It's rather long.
> 

When I said complex, I just meant long really.

> I'm not sure what you mean by the visiblePainted. As far as being the same
> issue as 404963, could be, I tried the examples, and things seemed quick.
> 

You can't do that in your case as you have mouse events connected to the paths.

Comment 11

[Helder "Lthere" Magalhães]

Attachment: Test case which doesn't show the symptom

This test case was originated during reduction of bug 404963, so one may want to take a look at the discussion (relevant part of the discussion during and after 23rd comment [1]).

Basically, the CPU increase is avoided by setting "pointer-events" [2] to "none" on static elements which are not to receive them. This is the standard way of «optimizing» this and makes the symptom go away - therefore IMHO this bug should (also) be marked invalid.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=404963#c23
[2] http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty

Comment 12

[Sean]

Attachment: Slow Mouseover

Comment 13

[Sean]

I've played with the pointer events, but that doesn't help. I don't see how bug 404963 is applicable, that one has pointer-events="none", whereas I want pointer-events. There are no mouseover events in the example.

Comment 14

[Sean]

Comment on attachment 317005 [details]
Slow Mouseover

My find replace messed up the pointer-events="visiblePainted", but seems to have no affect.

Comment 15

[Helder "Lthere" Magalhães]

Attachment: Possible workaround (for Firefox 2, Firefox 3 doesn't need it)

According to comment in related bug [1], a possible workaround would be splitting very long paths into smaller ones. This attachment puts the idea in practice, splitting the very long path into 4 smaller ones. Some (unrelated) smaller issues were also fixed.

The result is a noticeable performance boost in Firefox 2. In Firefox 3 the original attachment already didn't show the slowdown, so no (noticeable) performance boost felt.

Considering that symptoms aren't experienced in next major release (Fx3) as well as a workaround exist for current release (Fx2), IMHO this could be marked "fixed" or, at least, the bug's severity be lowered to a more reasonable value.


Minor issues found in original attachment:
 * typo in 'pointer-events="visib LePainted"' (already stated in comment 14);
 * function 'out2' changes fill to an invalid value (1), which will cause fill property to inherit. Although this is working, it's not recommended. Attachment has this issue fixed (sets proper color in method invocation).

(In reply to comment #14)
> (From update of attachment 317005 [details])
> My find replace messed up the pointer-events="visiblePainted", but seems to
> have no affect.
Can you please update your attachment to reflect the two small issues found?


Versions:
Firefox 2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Firefox 3 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042207 Minefield/3.0pre


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=404963#c22

Comment 16

[Robert Longson [:longsonr]]

As far as I know, Firefox 3 is still pretty slow processing large paths compared to other UAs, so I think it's reasonable to keep this open.

Comment 17

[Sean]

Attachment: Slow Mouseover w/o typo

Comment 18

[Sean]

I don't think this should be closed either. Reason being that, although Helder has shown a work around, in mapping, the borders are usually drawn. So splitting it into 4 would create odd looking borders. I just feel that if Adobe or Safari can achieve a certain performance, then it's not unreasonable to expect the same from Mozilla. They're capable.

Comment 19

[Helder "Lthere" Magalhães]

(In reply to comment #16)
> As far as I know, Firefox 3 is still pretty slow processing large paths
> compared to other UAs, so I think it's reasonable to keep this open.
Fair enough. :-)

(In reply to comment #18)
> So splitting it into 4 would create odd looking borders.
I don't agree on this. I've split the path in key locations (move commands), so I believe this workaround will look exactly as the original path. Only case that occurs to me, where this approach may not work as expected, is when "fill-rule" is set to "nonzero", which will cause the path split approach to break...

Comment 20

[Robert Longson [:longsonr]]

The original version seems to work pretty well now. Can we close this as WORKSFORME? This article probably details why performance has improved.

Comment 21

[Helder "Lthere" Magalhães]

(In reply to comment #20)
> The original version seems to work pretty well now. Can we close this as
> WORKSFORME? This article probably details why performance has improved.

Which article? Was there a missing paste here? ;-P

I just stumbled across a great article on Fx 3.6 JS improvements [1] but still I wasn't able to come up with anything there which could interfere with the path processing code. Am I missing something?

[1] http://hacks.mozilla.org/2010/01/javascript-speedups-in-firefox-3-6/

Comment 22

[Robert Longson [:longsonr]]

http://muizelaar.blogspot.com/2010/01/graphics-performance-in-firefox-36.html

Comment 23

[Helder "Lthere" Magalhães]

(In reply to comment #22)
> http://muizelaar.blogspot.com/2010/01/graphics-performance-in-firefox-36.html

Thanks for the link, Robert: was an interesting read. :-)

I've also read through the article and confirm the significant (somehow brutal?) improvement.

+1 for closing this as well.