Re: Significant performance degradation related to foreignObjects with scrollbars

I've done some more testing and improved the test case to better show the
problem I'm seeing.  It is at
http://informal.mine.nu:10080/docs/ForeignObjectBug2.svg

The main platform of my concern is Linux, and this issue is present in both
the current stable version (3.03) and the latest nightly.  For what it's
worth, I run Ubuntu 8.04.

The issue is also present in the Win32 build under both XP and Vista,
although not nearly as pronounced.  The test case is about 1100% more
efficient in Windows, with a 1.7Ghz Pentium M in XP vastly outperforming a
Core 2 Duo 3.5Ghz in Ubuntu, in a comparison of the left-most animation with
7 scrollbars onscreen.

What is consistent is that the two left-most animations become significantly
slower than the right-most animations as scrollbars are added, even when
added to entirely unreleated foreignObjects.  There is what appears to be an
anomalous region in the top left corner that interferes with rendering
efficiency in elements placed overtop it.

Note that at no point is the content of the foreignObjects changed during
the animation (except when explicitly changing scrollbars), nor do any SVG
elements actually overlap, and that there is no foreignObject element placed
in the top-left corner.

To show that clipping is not likely a major issue, I have added a "Toggle
Scrolling" option, that when enabled causes the content to marquee inside
the animating foreignObjects, regardless of whether scrollbars are enabled.
If tested with 0 scrollbars, you will see that the animation times remain
the same when this option is enabled, and that performance degrades linearly
as scrollbars are added anywhere onscreen.  It's best to keep it disabled
during other testing.

Finally, it is important to keep an eye on CPU usage if you have a fast CPU,
as that is sometimes the only way to see the slowdowns with few scrollbars
onscreen, as the animation times won't degrade but CPU usage will jump.

Thanks,

-Steve



On Sun, Nov 2, 2008 at 7:22 AM, Robert Longson <[email protected]> wrote:

> On Nov 2, 10:00 am, "Steve Hazel" <[email protected]> wrote:
> > Hi all,
> >
> > This set of problems look like three separate but related SVG issues,
> > centering around foreignObject handling.  I have put together a test case
> to
> > demonstrate the first two, accessible athttp://
> informal.mine.nu:10080/docs/ForeignObjectBugs.svg.
> >
> > The first two issues involve performance-degrading scrollbars in XHTML
> > foreignObjects.
> >
> > 1. Scrollbars in XHTML foreignObject content cause significant rendering
> > slowdowns across the entire SVG canvas.  The slowdown is approximately
> 18%
> > for each additional scrollbar-displaying foreignObject, in my test case.
>
> Without scrollbars i.e. if you don't have overflow, we can clip the
> content to the viewing region and thereby optimise drawing. Since we
> repaint everything (see below) clipping speeds things up I guess.
>
> > The remaining issue involves a side-effect for XHTML foreignObjects when
> > manipulating z-depth.
> >
> > 3. Z-depth (zIndex) control in SVG mirrors the DOM element order, but
> > changing this order using appendChild, insertBefore or insertAfter causes
> a
> > content redraw.  If this content is a foreignObject, it will be
> completely
> > reloaded and re-rendered every time its drawing order, or that of its
> group,
> > is changed.  Additionally, the foreignObject region, as described above,
> > flickers each time this content is reloaded and redrawn.  This makes it
> > impractical to dynamically manage shape drawing order, as required by an
> > interactive application, due to the significant performance hit and the
> > restrictions implied by the automatic (and seemingly unnecessary) content
> > reload.  I can provide a video demonstrating the flicker, if anyone wants
> to
> > see it.
>
> We know this one it's https://bugzilla.mozilla.org/show_bug.cgi?id=418063
>
> >
> > If anyone has insight into or opinions on any of these issues, I'd be
> happy
> > to hear it.  All of them look like bugs to me, and are serious enough to
> > hinder meaningful SVG-based application development.  Unless otherwise
> > indicated by someone more knowledgeable than myself, I'll be submitting
> them
> > as bugs in hopes of getting them fixed sometime soon.
>
> Patches are always welcome.
>
> Best regards
>
> Robert.
> _______________________________________________
> dev-tech-svg mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-svg
>