558161 - IE Flying Images demo is slow, even with D2D enabled

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Christopher Blizzard (:blizzard)]

The IE Flying Images demo is pretty slow in Firefox, even with DirectWrite and D2D enabled.  The IE9 preview, with 100 images loaded stays at a solid 50-60fps.  Firefox starts at 50fps but quickly drops down to 5-15.

Comment 1

[Bas Schouten (:bas.schouten)]

It would be interesting to see if the CPU is saturated on FF? To get an idea of how much time we spend blocking on the GPU executing commands.

Comment 2

[Bas Schouten (:bas.schouten)]

So, when I run this, I get about 20 fps. My CPU does not saturate, but it is quite high. It does not appear to be fillrate bound, making the window or images smaller makes no difference.

Comment 3

[Bas Schouten (:bas.schouten)]

This is caused by hitting fallback rendering because of an OPERATOR_SOURCE in imgFrame.cpp:456. This could probably use OptimalFillOperator() since it's drawing to a new surface for which OVER would be the same as SOURCE.

Comment 4

[Bas Schouten (:bas.schouten)]

I've tested this, with OptimalFillOperator I get 40 fps with 100 images. And the CPU is completely saturated, I suspect at that point the bottleneck is no longer in graphics stuff, although I haven't done enough testing to be sure.

Comment 5

[Bas Schouten (:bas.schouten)]

I've looked at this some more. The OptimalFillOperator only helps for some situations, and not for the general spinning around. However I have found out that there's a bug in the Cairo create brush code that makes us upload far too much data to the GPU, patch upcoming.

Comment 6

[Bas Schouten (:bas.schouten)]

Attachment: Remove dirty flag from cached bitmaps once reuploaded

We were not properly setting bitmaps !dirty once we re-uploaded them. This meant that once a cached bitmap was marked dirty once, it would forever re-upload to VRAM rather than the cache doing its job. This situation is the case for the flying images, this means that as we get more flying images, we have to upload the image again for every -instance- of the image. Rather than reusing the cached surface in VRAM. 

With this patch our performance goes up greatly in the flying images demo, and CPU usage drops to +/- 2-3% on my Core i7 920.

Comment 7

[Christopher Blizzard (:blizzard)]

I left that demo running, went away for 30 minutes, and came back to discover that Minefield had exited without a crash dialog.  Would that cause that behaviour?

Comment 8

[Bas Schouten (:bas.schouten)]

(In reply to comment #7)
> I left that demo running, went away for 30 minutes, and came back to discover
> that Minefield had exited without a crash dialog.  Would that cause that
> behaviour?

Hrm, it could be the continuous uploading to VRAM caused something nasty, it's not something you're supposed to do that much, but obviously it still shouldn't really crash, no real idea there.

Comment 9

[Bas Schouten (:bas.schouten)]

Pushed http://hg.mozilla.org/mozilla-central/rev/45ccb5f33635.

Comment 10

[IU]

(In reply to comment #8)
> (In reply to comment #7)
> > I left that demo running, went away for 30 minutes, and came back to discover
> > that Minefield had exited without a crash dialog.  Would that cause that
> > behaviour?
> 
> Hrm, it could be the continuous uploading to VRAM caused something nasty, it's
> not something you're supposed to do that much, but obviously it still shouldn't
> really crash, no real idea there.

I suspect he might have encountered this at the time: http://forums.mozillazine.org/viewtopic.php?p=9134505#p9134505

Comment 11

[u88484]

Confirmed fixed using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100413 Minefield/3.7a5pre

Thanks! I thought my FPS were so low because of my poppy hardware.