Bug 104693
Summary: | REGRESSION: Very poor performance on IE's Chalkboard benchmark | ||
---|---|---|---|
Product: | WebKit | Reporter: | Tim Horton <thorton> |
Component: | SVG | Assignee: | Philip Rogers <pdr> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | abarth, fmalita, krit, pdr, peter, schenney, zimmermann |
Priority: | P2 | Keywords: | InRadar, Regression |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://ie.microsoft.com/testdrive/Performance/Chalkboard/ |
Tim Horton
http://ie.microsoft.com/testdrive/Performance/Chalkboard/
A vague history of our performance on this test:
a) bad (15 seconds to completion, pretty jerky) before SVGImageCache (http://trac.webkit.org/changeset/99539)
b) sort of OK (5 seconds to completion, relatively smooth) after SVGImageCache, but pixelated.
c) absolutely horrific (hundreds of seconds to completion, completely stalling for seconds at a time) after Niko's fix to actually use the right image size. But not pixelated anymore. (http://trac.webkit.org/changeset/112229)
<rdar://problem/11769350>
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Florin Malita
I believe Philip is taking a hard look at the SVG image cache :)
FWIW, bypassing the SVG image cache completely (by hacking SVGImageCache::lookupOrCreateBitmapImageForRenderer to always return Image::nullImage for example) fixes this issue (runs in under 5s on my workstation, not pixelated).
Tim Horton
(In reply to comment #1)
> I believe Philip is taking a hard look at the SVG image cache :)
That is *fantastic* news.
> FWIW, bypassing the SVG image cache completely (by hacking SVGImageCache::lookupOrCreateBitmapImageForRenderer to always return Image::nullImage for example) fixes this issue (runs in under 5s on my workstation, not pixelated).
Heh, good to know!
Tim Horton
(In reply to comment #2)
> (In reply to comment #1)
> > I believe Philip is taking a hard look at the SVG image cache :)
>
> That is *fantastic* news.
pdr, do you have a bug tracking your work?
> > FWIW, bypassing the SVG image cache completely (by hacking SVGImageCache::lookupOrCreateBitmapImageForRenderer to always return Image::nullImage for example) fixes this issue (runs in under 5s on my workstation, not pixelated).
>
> Heh, good to know!
Philip Rogers
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I believe Philip is taking a hard look at the SVG image cache :)
> >
> > That is *fantastic* news.
>
> pdr, do you have a bug tracking your work?
I've been plugging away at this but our image cache is really not well :/ My current plan is to get the cache into a decent, working state and then switch it over to be non-image-based.
I went ahead and filed several of the larger bugs:
https://bugs.webkit.org/show_bug.cgi?id=106156
https://bugs.webkit.org/show_bug.cgi?id=106158
https://bugs.webkit.org/show_bug.cgi?id=106159 (this is the imagebuffer change)
Philip Rogers
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > I believe Philip is taking a hard look at the SVG image cache :)
> > >
> > > That is *fantastic* news.
> >
> > pdr, do you have a bug tracking your work?
>
> I've been plugging away at this but our image cache is really not well :/ My current plan is to get the cache into a decent, working state and then switch it over to be non-image-based.
>
> I went ahead and filed several of the larger bugs:
> https://bugs.webkit.org/show_bug.cgi?id=106156
> https://bugs.webkit.org/show_bug.cgi?id=106158
> https://bugs.webkit.org/show_bug.cgi?id=106159 (this is the imagebuffer change)
We now pass the IE chalkboard demo in 9s at 1280x1024!