613274 - IE Test Drive Galactic demo is slow

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[JK]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101118 Firefox/4.0b8pre

Like a slideshow.

IE9 pre 7: 430 km/s FPS 43
FF4b8 pre: 265 km/s FPS 15

Is this a graphics or JavaScript problem?

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

On Mac, certainly graphics (97% under drawImage on the canvas; 33% in the CoreGraphics resample_byte_h_3cpp_vector function, that sort of thing).  The page never gives me an FPS number or speed, fwiw.  I would be surprised if it's higher than 2-3 on Mac.

On Windows, I'd expect us to accelerate the drawImage call, but I bet this is still gated on graphics.

Comment 2

[Bas Schouten (:bas.schouten)]

On windows this looks a little different, quite possibly because we're much less bound by drawImage. On windows DrawImage itself accounts for at least 30-40% of the time. Interestingly about 25% is taken by another thread inside sqlite. Coming from nsUrlClassifierDBServiceWorker::UpdateStream.

Another 25% is spent inside PushLayer/PopLayer combinations inside D2D on the CanvasLayer. I'm looking into where these are coming from.

Comment 3

[Bas Schouten (:bas.schouten)]

So, this demo is actually doing a non-rectangular clip. And we suck at this. What surprises me a little bit is that IE9 is doing so much better, since I'm presuming they use the same D2D clipping functionality. It could however very well be that we end up doing things a lot less efficient because of the conversion dances we do between clipping models.

Comment 4

[Bas Schouten (:bas.schouten)]

Another interesting aspect makes this slower for us. The draw images here are drawn with a transform on the context. If you'd use the optimal approach you would SetTransform on the D2D render target. You'd then use a FillRectangle call. In our case Cairo will transform the rectangle to a non-rectangular shape and we then proceed to convert this to a D2D geometry and execute a FillGeometry call. This leads to a much less efficient drawing path, however I'm not sure there's much we can do about this.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Coming from nsUrlClassifierDBServiceWorker::UpdateStream.

That's a sporadic thing, and as you noted on a background thread.  We have existing bugs covering this bit....

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #4)
> Another interesting aspect makes this slower for us. The draw images here are
> drawn with a transform on the context. If you'd use the optimal approach you
> would SetTransform on the D2D render target. You'd then use a FillRectangle
> call. In our case Cairo will transform the rectangle to a non-rectangular shape
> and we then proceed to convert this to a D2D geometry and execute a
> FillGeometry call. This leads to a much less efficient drawing path, however
> I'm not sure there's much we can do about this.

Sure there is --- cairo_backend_t or something equivalent. Not for Firefox 4 though. I don't think we should block on this.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Well, I guess we could do something the existing D2D backend to detect when the path is a transformed rectangle and call SetTransform then FillRectangle.

Comment 8

[Joe Drew (not getting mail)]

Please renom when if & when this is confirmed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Uh...  This is very much confirmed.  Did you try just loading the page?  ;)

(That said, I'm not convinced this should block, so not renominating.)

Comment 10

[Scoobidiver (away)]

For me, it's around 350-450 km/s in IE 10 and Chrome 25 while only 130 km/s in Nightly/20130318.

Comment 11

[Gregory Pappas [:gregp]]

Still very slow