Bug 19118 – Animated SVG performs and renders really badly

• Component: SVG
• Status: NEW

[Oliver Hunt]

The linked SVG doesn't animate well/performantly, or render correctly.  This makes me sad :-(

[Oliver Hunt]

There appears to be a few issues,
 * The animation appears to be incorrectly centered.  A brief look at the code and the animation behaviour actually makes me think we're getting the mask position wrong.
 * There are some fairly severe repaint issues in the center of the image.
 * Style/fill information isn't updating properly.  Not sure if the is a painting, invalidation or updating issue.
 * Performance is just generically poor.

[Antti Koivisto]

Regarding the bad performance, almost all time is spent in text painting.

[Eric Seidel (no email)]

I've not looked at the profile.  But yes http://files.myopera.com/MacDev_ed/svg/svgtime/circularclip.svg renders pretty awfully.  I suspect most (if not all) of the repaint issues have been fixed by my recent rendering tree rewrite for SVG.   Obviously we have some perf work to do yet. :)

[Eric Seidel (no email)]

We still perform awful on this example.

[Simon Fraser (smfr)]

Created attachment 45165 [details]
Sample

Lots of time in SVGInlineTextBox::paintCharacters() and SVGResourceMasker::applyMask(). Sample attached.

[Dirk Schulze]

(In reply to comment #5)
> Created an attachment (id=45165) [details]
> Sample
> 
> Lots of time in SVGInlineTextBox::paintCharacters() and
> SVGResourceMasker::applyMask(). Sample attached.
I'm working on applyMask. I got it managed to make the code twice as fast as it is today on gtk. Not sure about the win on Cg, but there is still more potential.

[Simon Fraser (smfr)]

Ah, SVGResourceMasker::applyMask() is doing pixel-by-pixel stuff. No wonder this is slow. We've got to figure out a way to offload some of these filtering operations to the graphics system and/or hardware if we can.

[Dirk Schulze]

(In reply to comment #7)
> Ah, SVGResourceMasker::applyMask() is doing pixel-by-pixel stuff. No wonder
> this is slow. We've got to figure out a way to offload some of these filtering
> operations to the graphics system and/or hardware if we can.

We had a CI implementation on Masker. But it just works on Mac, the results were sometimes wrong and it took 10 times longer on my Mac (with a simple intel chip).
It would be sad to add platform dependent code on SVG again. If you figure out a hardware accelerated way to make this filtering, it would be the best to put it to the platform code (e.g. ImageBufferCg). We would just call it, if the platform supports a fast filtering operation.

I wrote a patch that makes the image manipulation faster. Now I try to figure out the smallest visible area of the ImageBuffer. This will also be a win.

[Simon Fraser (smfr)]

(In reply to comment #8)

> It would be sad to add platform dependent code on SVG again. If you figure out
> a hardware accelerated way to make this filtering, it would be the best to put
> it to the platform code (e.g. ImageBufferCg). We would just call it, if the
> platform supports a fast filtering operation.

Any hardware acceleration that we do would be opt-in, and in addition to a software path, and would only be taken when the results can be guaranteed to be accurate.

I'm not sure how we'd organize the code yet.

[Dirk Schulze]

(In reply to comment #9)
> (In reply to comment #8)
> 
> > It would be sad to add platform dependent code on SVG again. If you figure out
> > a hardware accelerated way to make this filtering, it would be the best to put
> > it to the platform code (e.g. ImageBufferCg). We would just call it, if the
> > platform supports a fast filtering operation.
> 
> Any hardware acceleration that we do would be opt-in, and in addition to a
> software path, and would only be taken when the results can be guaranteed to be
> accurate.
> 
> I'm not sure how we'd organize the code yet.

Bug 32738 makes SVG Mask faster. The pixel manipulation just performs on creating the MaskResource and not on every applyMask() call. The mask imageBuffer is as small as possible.
If applyMask() is still to slow, it's the problem of GraphicsContext::clipToImageBuffer and we should ask the Cg folks to use HW accelerators or perform better some how ;-)

[Rob Buis]

I think bug 48361 points at the same svg file (though that report has a reduction). Time to mark one as duplicate?
Cheers,

Rob.

[Dirk Schulze]

*** Bug 48361 has been marked as a duplicate of this bug. ***

[Nikolas Zimmermann]

Reduction without masks, use or anything:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 800 800">
    <text id="text" y="40" font-family="Impact" font-size="48" transform="rotate(-8 400 400)">
      <tspan>Time is running. Do you have the time? Lunchtime.</tspan>
      <tspan dy="1em" x="0">Tick tock tick tock. Seven o'clock. Tick tock.</tspan>      
      <tspan dy="1em" x="0">Watch out. 6.30am, August 27, 2013. Glue.</tspan>      
      <tspan dy="1em" x="0">Did you see 23:23 on the alarmclock again?</tspan>      
      <tspan dy="1em" x="0">In Tokyo it's already noon. But you are somewhere else.</tspan>      
      <tspan dy="1em" x="0">Wake up, time for work. When is the meeting?</tspan>      
      <tspan dy="1em" x="0">Are you late? What time is it? Snoozing polar bears.</tspan>      
      <tspan dy="1em" x="0">4pm. The taxi is waiting. Scheduled plans.</tspan>      
      <tspan dy="1em" x="0">In a way it's already December. Validate.</tspan>
      <tspan dy="1em" x="0">The summer is coming, but it's still spring.</tspan>      
      <tspan dy="1em" x="0">Can't wait any longer. Cold storage required.</tspan>      
      <tspan dy="1em" x="0">Early morning hacking. Infinitesimal loop iterations.</tspan>
      <tspan dy="1em" x="0">The milk expired while I read the newspaper.</tspan>      
      <tspan dy="1em" x="0">A kiss as I left in the morning. Do you have the timetable? </tspan>      
      <tspan dy="1em" x="0">Travelling to Nice, France. Bonjour I suppose.</tspan>
      <tspan dy="1em" x="0">13 hundred hours. Time flying. Is it bedtime yet?</tspan>      
      <tspan dy="1em" x="0">Are we there yet? Killing time in Amsterdam.</tspan>
    </text>

  <animateTransform type="rotate" values="0 400 400;360 400 400" dur="360s" repeatDur="indefinite" attributeName="transform" xlink:href="#text"/>
</svg>

This still consumes 100% CPU for us in release builds, FF is at 85%, Opera around 10%.
Intstruments says almost all time is spent inside CoreGraphics, I have to look deep to find WebCore functions.

Even simpler test:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 800 800">
<text id="text" y="40" font-family="Impact" font-size="48" transform="rotate(-8 400 400)">Time is running. Do you have the time? Lunchtime.</text>
<animateTransform type="rotate" values="0 400 400;360 400 400" dur="360s" repeatDur="indefinite" attributeName="transform" xlink:href="#text"/>
</svg>

Both FF & us consume around 25% cpu for that.
I'm attaching a screenshot of Instruments while running the simple testcase for 1 minute.

[Nikolas Zimmermann]

Created attachment 131590 [details]
Instruments screenshot

[Nikolas Zimmermann]

<html>
<head>
  <style type="text/css">

svg {
    left: 50px;
    top: 50px;
    position: absolute;
    -webkit-transition: all 2s ease-in-out;
}

svg:hover {
    -webkit-transform: rotate(180deg);
}
</style>
</head>
<body>

<svg viewBox="0 0 800 800">
    <text class="text" y="40" font-family="Impact" font-size="48" transform="rotate(-8 400 400)">
      <tspan>Time is running. Do you have the time? Lunchtime.</tspan>
      <tspan dy="1em" x="0">Tick tock tick tock. Seven o'clock. Tick tock.</tspan>      
      <tspan dy="1em" x="0">Watch out. 6.30am, August 27, 2013. Glue.</tspan>      
      <tspan dy="1em" x="0">Did you see 23:23 on the alarmclock again?</tspan>      
      <tspan dy="1em" x="0">In Tokyo it's already noon. But you are somewhere else.</tspan>      
      <tspan dy="1em" x="0">Wake up, time for work. When is the meeting?</tspan>      
      <tspan dy="1em" x="0">Are you late? What time is it? Snoozing polar bears.</tspan>      
      <tspan dy="1em" x="0">4pm. The taxi is waiting. Scheduled plans.</tspan>      
      <tspan dy="1em" x="0">In a way it's already December. Validate.</tspan>
      <tspan dy="1em" x="0">The summer is coming, but it's still spring.</tspan>      
      <tspan dy="1em" x="0">Can't wait any longer. Cold storage required.</tspan>      
      <tspan dy="1em" x="0">Early morning hacking. Infinitesimal loop iterations.</tspan>
      <tspan dy="1em" x="0">The milk expired while I read the newspaper.</tspan>      
      <tspan dy="1em" x="0">A kiss as I left in the morning. Do you have the timetable? </tspan>      
      <tspan dy="1em" x="0">Travelling to Nice, France. Bonjour I suppose.</tspan>
      <tspan dy="1em" x="0">13 hundred hours. Time flying. Is it bedtime yet?</tspan>      
      <tspan dy="1em" x="0">Are we there yet? Killing time in Amsterdam.</tspan>
    </text>
</svg>
</body>
</html>

And now compare with this. Hovering this SVG results in a blazing fast transition that doesn't consume any cpu :-)

[Ahmad Saleem]

I was able to retrieve SVG using Wayback Archive once again and I turned it into JSFiddle: 

Link - https://jsfiddle.net/69n31aeg/show

This SVG is still stress test for Safari and animations are not as smooth as other browsers (Chrome Canary 105 and Firefox Nightly 104) while using Safari 15.5 and Safari Technical Preview 148 on macOS 12.4 (M1 Pro machine). Thanks!

[Karl Dubost]

Created attachment 478888 [details]
testcases

The performances are not too bad. 
Chrome/Safari: 60 FPS
Firefox: 120 FPS

Safari has a little stuttering time to time 
But Firefox/Chrome have a more regular scrolling without stuttering when the window is upfront. Once the window goes in the back the performances degrade.

For example in 3. Animated Text with Gradient Fill, the characters have a bit of accordion effect in Safari.