Closed Bug 404963 Opened 17 years ago Closed 16 years ago

SVG eating CPU when it shows USE elements

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: desss, Unassigned)

References

(
URL
)

Details

Attachments

(4 files, 1 obsolete file)

Reduced test-case of original attachment
130.59 KB, image/svg+xml
Details
Simpler, interactive, test case
1.29 KB, image/svg+xml
Details
Adapted version of test case which splits down complex path - improved behavior in Firefox 3
1.41 KB, image/svg+xml
Details
Fixed test case
1.42 KB, image/svg+xml
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

After opening this page Fifefox3b1 works too slow.

Reproducible: Always

Steps to Reproduce:
1.click "zoom in" button and check execution time of this event
2.then click "hide marks" ("USE" elements in svg) and click "zoom in"
3.Compare cpu usage.


Expected Results:  
fast work with "use" elements

Opera, IE with ASV3.03 and Safari3 beta works fine and fast.
Please submit a minimal testcase rather than a 800Kb zip file.
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Size of monitoring.zip  - 189kb
ok:) I refilled it. Now 149(760)kb
Try to produce something as a single file in less than 1kb please and submit it as an attachment.
I fixed it in zip-file and sent copy at your mailbox.
Fixed what? Please try to address comment 5 and please don't send me private emails. c.f. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html 1.4

i thought that you have trouble with opening html. There was not all pieces of html.
So what are you talking about? what file do you mean?
I would like you to produce a single simple SVG file demonstrating the problem. That single SVG file to be preferably less that 1Kb in size, not be zipped and be attached to bugzilla using the "Add an attachment" facility above.
hmm... I don't see another way to demonstrate this problem especially on small svg-file. It able to see only that we have a few tens objects as <use> elements and manupilating it's visibility.

Second button from bottom at toolbar between list at left and svg-map calls "show/hide marks".

When marks(<use>) is hiding, zooming of svg-map is more or less fast.
If marks shown - cpu usage increase twice.
Just click "zoom in" button (resizing svg object by JS) and you will see it.

It should be noted that during the infinite loop (or whatever it is) firefox lacks some functionality. For example, I couldn't browse the filesystem to save the the file from "View Page Source".

And yes, if 'use' is removed, the loop is gone.
Also, it's gone if the stuff inside 'use' is off screen.
Hereby confirming also on Linux.

Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9b3pre) Gecko/2008011104 Minefield/3.0b3pre
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
No, Robert Longson, this bug is not the same your's "duplicate"!
I didn't wrote about text in filter. I meant work with <use> element in firefox as a whole.
As i see by posts dates, Mozilla's team don't care about this bug.
Resolution: DUPLICATE → INCOMPLETE
I thought you had finally done what I asked you to do in Comment 9, i.e. break down the 760Kb file into a simple 1-2Kb file demonstrating the problem. Perhaps I should have checked more carefully on whether it was actually you who did that.

Anyway firstly, is the attachment in comment 11 an extract from your 760 kb file? If so Ivan's comments are valid and this bug IS a duplicate of bug 411555 and you should thank him for doing this work. Had you done it yourself this bug would have been fixed much earlier. After all why should I spend my free time breaking down a 760Kb file into a simple testcase when you could do that yourself.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
No, I discovered the bug independently and got here by searching for 'svg' and 'cpu' ;)
The attachment is not an extract from anything. I have asumed that my testcase addresses the same problem, so I didn't open a new bug for it, but posted it here.
Ivan your issue is a duplicate of bug 411555.
Attachment #296670 - Attachment is obsolete: true
Yes, really. Your's unzipping file will take much of your's very expensive time.:\
Please, read comment #10 at this: "I don't see another way to
demonstrate this problem especially on small svg-file. It able to see
only that we have a FEW TENS objects as <use> elements and manupilating
it's visibility.". 
As i thought you had propose to me to rebuild(rewrite) HTML and SVG files with all javascript functionality into one damn simple small svg-file which will not show any symptoms of this trouble.:\ 
So, i had draw conclusion that you just finding causes to ignoring this trouble.
When i wrote about bug at webkit.org there was no any trobles with this zip.
With such your wish to research this bug i don't want write something here in the future. 
Koroche, zaebal ty chuvak.
You could try putting some javascript timing in to demonstrate that perhaps use elements scale non-linearly with number present, or perhaps the timing will show that webkit is much faster on a particular use scenario. All I am trying to say is written much better in http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

I am sorry you feel frustrated, unfortunately there are many more bugs raised than there are developers to look at them.
OS: Windows XP → All
Hardware: PC → All
Stripped down version of Dmitriy's original attachment (available at bug report's URL) - showing the Sea of Azov [1], in case someone is curious... :-)

I was able to isolate the CPU eating behavior to a single path containing many points (almost 3000).

Note: Attachment is still somehow large (about 130 KB). Further analysis and a simpler test case follow.

[1]http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=111778547115876720061.000442ee9d5b24e2af063&om=1&ll=46.278631,36.749268&spn=3.13582,7.470703&z=7&iwloc=000442f042ef90d88f4fc
Interactive test case - generates a path which shows original symptoms.

Reproducible: Always

Steps to Reproduce:
1.Open attachment "Simpler, interactive, test case";
2.Enter a big number such as 5000 (although above 1500 should do the trick);
3.Mouse over the red container. Move the mouse within this rectangle;
4.Mouse over the region between the document (blue) container and the red container. Move the mouse within this region.

Actual Results:
High CPU usage in step 3.

Expected Results:  
No CPU usage increase in step 3.

Additional Information:
Seems that it's (weirdly) trying to get the path's bounding box or similar, as the high CPU load only occurs within (the path's bounding box). This is somehow strange as:
 * The document is static (no "onmouseover"s and/or declarative events);
 * Even if needed, bounding box could be cached and computed once (until some property change forces recomputing it).
With some additional difficulty, this behavior can also be experienced in previous attachment ("Reduced test-case of original attachment") - problem is that path occupies almost the whole document so it's difficult to make mouse movements over the thin remaining areas.

Some other experiments made:
 * Converted previous attachment ("Reduced test-case of original attachment") to line segments only - no improvement, which proved the symptom hasn't got to do with arc segments (most common path commands in previous attachment);
 * Tested with fill and no fill, to check for a possible paint server erroneous behavior - no changes, so not from that; 
 * Split path into equivalent simpler paths (underway in a follow up attachment).

IMHO this bug's title should be changed to "High CPU usage when moving mouse over complex path".

This seems to be an issue in both Firefox 2 and 3. Currently tested in Linux (Ubuntu 7.10) only - Windows will follow whenever possible.

Versions:
Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041204 Minefield/3.0pre
This attachment is a quickly adapted version of attachment 315675 [details], but here the unique complex path is split down to several paths of up to 250 points. (Note that a multiple of 250 should now be used as input.)

The attachment shows the same behavior in Firefox 2, and an improved behavior in Firefox 3 - maybe/probably related to bug 423998, which seems to be masking the underlying issue. 

This shows a possible (although Fx3-specific) workaround - splitting complex paths into simpler ones - until this issue is further analyzed/isolated/fixed.
(In reply to comment #21)
> Additional Information:
> Seems that it's (weirdly) trying to get the path's bounding box or similar, as
> the high CPU load only occurs within (the path's bounding box). This is somehow
> strange as:
>  * The document is static (no "onmouseover"s and/or declarative events);

Incorrect, the lines have a style of pointer-events="visiblePainted" see http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty. Set this to none and you should see cpu use decline.

>  * Even if needed, bounding box could be cached and computed once (until some
> property change forces recomputing it).

The bounding box is already cached.

> IMHO this bug's title should be changed to "High CPU usage when moving mouse
> over complex path".

We have a bug on that - bug 319990 although the testcase for that has disappeared so I could change this bug's title and dup that one to this.


(In reply to comment #22)
> The attachment shows the same behavior in Firefox 2, and an improved behavior
> in Firefox 3 - maybe/probably related to bug 423998, which seems to be masking
> the underlying issue. 

I doubt bug 423998 has any effect here as that bug is about text, not paths. If there is some issue with paths post bug 423998 then you should raise a new bug.

> 
> This shows a possible (although Fx3-specific) workaround - splitting complex
> paths into simpler ones - until this issue is further analyzed/isolated/fixed.
> 

If you split the paths then they each have their own bounding box so the pointer-events code can discard them cheaply.

(In reply to comment #21)
> Windows will follow whenever possible.
Same behavior experienced in Windows also - (roughly) confirms the hypothesis of not being an OS-specific issue.

Versions:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041406 Minefield/3.0pre


(In reply to comment #23)
> Incorrect, the lines have a style of pointer-events="visiblePainted" see
> http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty. Set this to none
> and you should see cpu use decline.
Thank you for pointing that out, wasn't aware of that. Seems a much cleaner «workaround» for this behavior! :-) BTW: couldn't this be (internally set as default) until element had some event registered (script/declarative)? Or would it violate the spec? Currently, text selection isn't supported, so this approach might generally improve performance without hurting much... Or is it too naive?


(In reply to comment #24)
> I doubt bug 423998 has any effect here as that bug is about text,
> not paths. If there is some issue with paths post bug 423998
> then you should raise a new bug.
What I meant was that the improvements introduced after fixing bug 423998 seem to help masking the behavior in Fx3 vs. Fx2.

> If you split the paths then they each have their own bounding box so the
> pointer-events code can discard them cheaply.
Also though so. Thanks for clearing it up.
(In reply to comment #25)
> Thank you for pointing that out, wasn't aware of that. Seems a much cleaner
> «workaround» for this behavior! :-) BTW: couldn't this be (internally set as
> default) until element had some event registered (script/declarative)? Or would
> it violate the spec? Currently, text selection isn't supported, so this
> approach might generally improve performance without hurting much... Or is it
> too naive?

We support all the uses of pointer-events listed in the specification. So we'd have to track 

    * user interface events such as mouse clicks
    * dynamic pseudo-classes (i.e., :hover, :active and :focus) [CSS2-DYNPSEUDO]
    * hyperlinks (see Links out of SVG content: the 'a' element)

which seems complicated. Especially when users can do something much simpler to fix it themselves.

I'm why you raise text selection when the issue is about paths.

(In reply to comment #26)
> (...)
> which seems complicated. Especially when users can do something much simpler to
> fix it themselves.
Seems fair to me. Maybe some evangelism is necessary here, as I believe many authors/developers (as myself) aren't aware of this (small but important) detail. Maybe a post to SVG developers [1] would help...?

> I'm why you raise text selection when the issue is about paths.
I was referring to an optimistic approach were all elements would start with pointer events set to none until an event registration (CSS/script/declarative/hyperlink) was detected. That's why I've referred to text, which could be affected if text selection was implemented and a quick-and-dirty implementation if this idea was conducted. Sorry if mixing things up made it a bit more confuse. ;-)

[1]http://tech.groups.yahoo.com/group/svg-developers/
(In reply to comment #27)
> Seems fair to me. Maybe some evangelism is necessary here, as I believe many
> authors/developers (as myself) aren't aware of this (small but important)
> detail. Maybe a post to SVG developers [1] would help...?

Why not, perhaps you could also get jwatt to add this tip to his svg authoring guidelines. http://jwatt.org/svg/authoring/
Attached image Fixed test case — 
Test case based in attachment 315675 [details], updated for Robert Longson's suggestion (comment 23).

The change introduced is the standard way of optimizing things and causes the symptom no longer to appear so, IMHO, this issue can safely be marked "invalid".
Comment on attachment 315675 [details]
Simpler, interactive, test case

Could you move this testcase into bug 319990 please?
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → INVALID
So, after all, the obtained conclusion seems to be:
«Use "pointer-events" set to "none" in layers (implemented as groups) with static content, where surely there are no events to receive pointer attention.» [1]. One may also take a look at bug 319990 which is related.


(In reply to comment #27)
> (In reply to comment #26)
> Maybe some evangelism is necessary here, as I believe many
> authors/developers (as myself) aren't aware of this (small but important)
> detail. Maybe a post to SVG developers would help...?

A post was sent to SVG developers group [1] in a related thread which was recently raised.


(In reply to comment #28)
> Why not, perhaps you could also get jwatt to add this tip to his svg authoring
> guidelines. http://jwatt.org/svg/authoring/

Good idea! :-) Although Jonathan Watt is already CC'ed into this bug, a short message was sent to him regarding what's being discussed here.


(In reply to comment #30)
> Could you move this testcase into bug 319990 please?

Done! :-)

[1] http://tech.groups.yahoo.com/group/svg-developers/message/60356
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: