115247 - Unnecessary repainting of lower z-index blocks slows down browser

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect, P1)

Description

[Marc Boullet]

BuildId 2001121203 NT4.
Not sure that the "View" component is the right one.

Look at the two testcases.

The first one works normally.
In the second one, I've added 5 DIVs with z-indexes from 1 to 5.
See the difference in speed when you scroll the cursor.

I'm not a specialist of Mozilla code, but I think that when you
repaint after the script has moved the cursor, you repaint all "layers".

Mozilla should be smart enough to know that if a "layer" has been repainted
with something opaque, all "layers" with a lower z-index don't
need repainting.

I noticed that Moz is today smart enough not to repaint the "layers" if
they don't overlap with original dirty rectangle (i.e., if you change
height="500" width="800" with height="10" width="10", the discernable speed
is the same as in testcase 1).

Comment 1

[Marc Boullet]

Attachment: image 1 necessary for the testcase

Comment 2

[Marc Boullet]

Attachment: image 2 necessary for the test case

Comment 3

[Marc Boullet]

Attachment: testcase 1

Comment 4

[Marc Boullet]

Attachment: transparent 1x1 png for testcase2

Comment 5

[Marc Boullet]

Attachment: testcase 2. Very slow compared against testcase 1.

Comment 6

[Kevin McCluskey (gone)]

Don, I think this is another example of slow tiling performance with png's.

Comment 7

[Kevin McCluskey (gone)]

Reassigning to Don.

Comment 8

[Marc Boullet]

Attachment: transparent 1x1 .gif

the problem is not exclusive of .png transparent files. The same occurs
with transparent .gif.
I will attach a new testcase where you can select the type of
image in the background DIVs (either 1x1 transparent .png or .png
or a blank .gif image).

Comment 9

[Marc Boullet]

Attachment: blank 800x500 .gif for testcase3

Comment 10

[Marc Boullet]

Attachment: testcase3

With this testcase, you're able to select the type of image
in the background DIVs.

Obviously, transparent images (.png or .gif) are a big problem.

Nevertheless, when I use a blank image, there is also a slowdown.
This may not be perceptible, but on my 300 MHz Pentium III, when
I move reasonably fast the cursor (i.e. my mouse is still alive
after), CPU usage goes 100% while, in testcase 1, it tops at 40%.

By the way, Kevin's analysis does not address my concern which
is that we should not repaint these backgroung DIVs, since the repaint of
the dirty rectangle by the DIV at z-index=6 is enough.

I know (and understand) that it is not the right season for DHTML bugs, so do
your best.

Comment 11

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

What this bug seems to be asking for is to recognize that "potar" consists only
of an image which is fully opaque, and use that knowledge in rendering. Right
now we don't attempt to do that; it's quite hard because we have to look at the
image data and recognize that there are no transparent pixels.

If we want to fix this, I suggest we modify nsImageFrame and possibly libimg so
that when an image is fully loaded it reports whether or not it contains any
transparent pixels (maybe we already have notifications for this?). If it
reports that it has no transparent pixels then nsImageFrame can create a view
for itself and mark the view as opaque. The view manager will then do the right
thing.

This should definitely be targeted post-1.0.

Comment 12

[Marc Boullet]

Attachment: new testcase

Comment 13

[Markus Hübner]

Is this also related to bug 139986 ?

Comment 14

[Marc Boullet]

I wrote a better testcase for this bug.
The changes are:
  1. the background "layers" can be created/destroyed dynamically.
  2. the number of background "layers" can be set dynamically to cope
     with various computer speeds (max 200).
  3. add a big text box just to type in.

This bug also affects very badly form controls (text box in the testcase).
To reproduce:
1. set the number of background <divs> to, say, 50.
2. Focus the "practice" text box and keep pressing any key.
3. See the characters enter the text box at a very very slow rate.

See also how slow is the dropdown select box with 50 layers.

Don't we know that the text box is fully opaque ?

Comment 15

[Jesse Ruderman]

Related to bug 34887, "Need to optimize painting of overlapping opaque frames"?

Comment 16

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

yes, they're related, although neither one blocks the other.

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

Hmm... tell me please, isn't it a result of silly algorytm of selecting layers?
On my machine when i'm trying to move layer in second testcase, after mousedown
and during Drag&Drop this layer is marked as selected, and probably underlaying
layer too... It few moments when Mozilla doesnt selecting and deselecting layers
it works quite fast...

Comment 18

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ok. I checked "new testcase" and it cannot be related only to problem with
"selecting", but i still feel that it could be connected to this. "testcase 2"
shows this problem.

Comment 19

[Boris Zbarsky [:bzbarsky]]

There's a bit of a problem with deciding that the image only contains opaque
pixels... what about animated gifs?  We couldn't make that decision till we got
all the way to the end of the gif, right?

In any case, if we can expose a boolean on imgIContainer or something that
reports that information, it would be quite nice....

Comment 20

[Adam D. Moss]

Sometimes it's very easy to tell (from just the first six bytes in the file :))
that a GIF isn't going to have any transparent pixels: GIF87a files never do. 
We could rely on this a whole lot more if GIF-writing programmers were less lazy
and used the spec's recommendation to save files with the lowest-necessary GIF
version.

As it is, from a quick and very dirty poll, about 30% of opaque (+non-animated)
GIFs in the wild correctly specify GIF87 headers.  In these cases we know the
GIF will be opaque very easily before starting to do any decoding.

For the rest... the idea of scanning the composed pixel data we end up with
every frame for transparency seems pretty expensive (though could just scan the
last frame if it's non-looping or non-animated), but given my rough test above,
fully-opaque-images-incorrectly-regarded-as-gif89 might be the common case, so
it could work out as a win when it comes to cheaper painting.

Comment 21

[Adam D. Moss]

Back to *animated* GIFs... there are other cases where we can relatively cheaply
(albeit not trivially) determine guaranteed opacity of an (animated) GIF without
scanning or decoding any pixel data, but even these, as you say, do require
having at least parsed the whole file once through already.

Comment 22

[Markus Hübner]

Anyone willing to take this?

Comment 23

[David Zbarsky (:dzbarsky)]

Whats the status on this one?

Comment 24

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

No-one's working on it. This would require new imagelib APIs.

Comment 25

[Zibi Braniecki [:zbraniecki][:gandalf]]

it seems to WFM for me with recent trunk Firefox3beta5pre.

Comment 26

[Wayne Mery (:wsmwk)]

if I understand the testcase correctly, this is also WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre

Comment 27

[Worcester12345]

(In reply to comment #22)
> Anyone willing to take this?

(In reply to comment #23)
> Whats the status on this one?

(In reply to comment #24)
> No-one's working on it. This would require new imagelib APIs.

(In reply to comment #25)
> it seems to WFM for me with recent trunk Firefox3beta5pre.

With nobody working on it, how did it suddenly start working?

Comment 28

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

Beats me, but I don't feel like finding out.