Unnecessary repainting of lower z-index blocks slows down browser

RESOLVED WORKSFORME

Status

()

P1
normal
RESOLVED WORKSFORME
17 years ago
27 days ago

People

(Reporter: boullet.marc, Assigned: roc)

Tracking

(Blocks: 1 bug, {helpwanted, perf, testcase})

Trunk
mozilla1.1beta
helpwanted, perf, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments)

(Reporter)

Description

17 years ago
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).
(Reporter)

Comment 1

17 years ago
Created attachment 61734 [details]
image 1 necessary for the testcase
(Reporter)

Comment 2

17 years ago
Created attachment 61735 [details]
image 2 necessary for the test case
(Reporter)

Comment 3

17 years ago
Created attachment 61738 [details]
testcase 1
(Reporter)

Comment 4

17 years ago
Created attachment 61739 [details]
transparent  1x1 png for testcase2
(Reporter)

Comment 5

17 years ago
Created attachment 61740 [details]
testcase 2. Very slow compared against 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
(Reporter)

Comment 8

17 years ago
Created attachment 62352 [details]
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).
(Reporter)

Comment 9

17 years ago
Created attachment 62354 [details]
blank 800x500 .gif for testcase3
(Reporter)

Comment 10

17 years ago
Created attachment 62355 [details]
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.

Updated

17 years ago
Target Milestone: --- → mozilla1.1

Updated

17 years ago
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.

Updated

17 years ago
Keywords: perf, testcase
(Reporter)

Comment 12

17 years ago
Created attachment 82449 [details]
new testcase

Comment 13

17 years ago
Is this also related to bug 139986 ?
(Reporter)

Comment 14

17 years ago
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 ?

Updated

17 years ago
Blocks: 21762

Updated

17 years ago
Target Milestone: mozilla1.1alpha → mozilla1.1beta

Updated

16 years ago
Keywords: mozilla1.1

Comment 15

16 years ago
Related to bug 34887, "Need to optimize painting of overlapping opaque frames"?
yes, they're related, although neither one blocks the other.

Updated

16 years ago
Keywords: mozilla1.2

Updated

16 years ago
Keywords: mozilla1.1, mozilla1.2 → mozilla1.3
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....

Comment 20

15 years ago
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

15 years ago
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

Updated

15 years ago
Blocks: 203448

Updated

15 years ago
Assignee: dcone → nobody
Keywords: mozilla1.3
Priority: P1 → --
QA Contact: chrispetersen → nobody
Target Milestone: mozilla1.1beta → ---

Updated

15 years ago
Assignee: nobody → dcone
Keywords: mozilla1.3
Priority: -- → P1
QA Contact: nobody → chrispetersen
Target Milestone: --- → mozilla1.1beta

Comment 22

14 years ago
Anyone willing to take this?

Updated

14 years ago
Assignee: dcone → roc
Keywords: mozilla1.3 → helpwanted
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

Comment 26

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME

Comment 27

8 years ago
(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
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.