Closed Bug 115247 Opened 21 years ago Closed 13 years ago

Unnecessary repainting of lower z-index blocks slows down browser

Categories

(Core :: Web Painting, defect, P1)

defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.1beta

People

(Reporter: boullet.marc, Assigned: roc)

References

Details

(Keywords: helpwanted, perf, testcase)

Attachments

(9 files)

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).
Attached file testcase 1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Don, I think this is another example of slow tiling performance with png's.
Reassigning to Don.
Assignee: kmcclusk → dcone
Attached image 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).
Attached file 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.
Target Milestone: --- → mozilla1.1
Priority: -- → P1
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.
Keywords: perf, testcase
Attached file new testcase
Is this also related to bug 139986 ?
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 ?
Blocks: 21762
Target Milestone: mozilla1.1alpha → mozilla1.1beta
Keywords: mozilla1.1
Related to bug 34887, "Need to optimize painting of overlapping opaque frames"?
yes, they're related, although neither one blocks the other.
Keywords: mozilla1.2
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...
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.
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....
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.
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.
OS: Windows NT → All
Hardware: PC → All
Blocks: 203448
Assignee: dcone → nobody
Keywords: mozilla1.3
Priority: P1 → --
QA Contact: chrispetersen → nobody
Target Milestone: mozilla1.1beta → ---
Assignee: nobody → dcone
Keywords: mozilla1.3
Priority: -- → P1
QA Contact: nobody → chrispetersen
Target Milestone: --- → mozilla1.1beta
Anyone willing to take this?
Assignee: dcone → roc
Keywords: mozilla1.3helpwanted
QA Contact: chrispetersen → ian
Whats the status on this one?
No-one's working on it. This would require new imagelib APIs.
it seems to WFM for me with recent trunk Firefox3beta5pre.
QA Contact: ian → layout.view-rendering
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
(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?
Beats me, but I don't feel like finding out.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.