15408 - Performance problems with absolutely positioned inline element

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[Ian Graham]

The example document has an absolutely positioned div that
contains an absolutely positioned em (inside a p). The
Formatting of the em is just weird -- it formats into a
vertical column that spans dozens of viewport heights .....
which makes no sense at all. This can be fixed by setting
a fixed CSS height for the em block, but that shouldn't be
necessary.

The redraw time on this example is also absurdly slow. Much
of the redraw slowness is due to the background image
painted behind the div.

This is on the M9 Build (Win 98).

Comment 1

[troy]

Fixed. You may think that the height of the blue box is larger than you would
like, but we're doing what the spec says. See bug #15388 for the gory details.

Comment 2

[Christine Hoffman]

Using 12/2 build, verified fixed

Comment 3

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 4

[Ian Graham]

The CSS behavior is correct, but the example document causes the browser
to slow to a crawl -- page redraws take an absurdly long time. I don't 
know if (or where) this bug should be migrated to denote this performance
problem, so I am reopening it for someone with more expertise to reclassify
or close.
[This behavior seen on Mozilla 0.7, WIndow 98PC @ 450MHz ]

Comment 5

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 6

[Hixie (not reading bugmail)]

Ian: It works for me -- on Windows 2000 I get blazingly fast repaints on this 
page. Could you try this again on a recent build?

Comment 7

[Ian Graham]

I'll download a newer build this weekend, and let you know.

Comment 8

[Ian Graham]

Ok, I checked the nightly build dated 16/feb, and indeed it 
is more zippy. However, I do still see a noticeable redraw
lag if I quickly resize the window to be much wider: (i.e.,
take a narrow window, rapidly drag the _right_ edge as far
right as possible, and then watch for redrawing/filling). 
I then see somewhat slow filling of the background -- it
fills part way out to the right edge, and then  later fills 
in the rest. 

I do not see this if I rezize by dragging the _left_ edge of
the browser window -- in this case, there is sometimes jerkiness
in moving the left window edge, but the filling of the canvas
is smooth and seamless.

I did another simple test -- I put a window in front of Mozilla,
and then popped mozilla to the foreground. Again I see a noticeable
delay before the content is redrawn.

I then created a second example with only a page background 
graphic and an h1 element -- 
http://www.java.utoronto.ca/NS5-bugs/posn-bug-noposn.html
This shows the same issue just described -- if I pop Mozilla
to the foreground (from behind another window) there is a 
noticeable lag before the content and background is redrawn.

To test if this might be a graphics/processor issue, I tried the
same test just described with IE 5.5 and Navigator 4.x. Neither 
show the redraw delay observed with Mozilla.

For reference, I'm running Win98 (2ed) on a Dell Dimension 
XPS @ 450 MHz, with 128Mb ram (Mozilla's the only app), 
and have a 16mb 3dfx Voodoo3 3000 AGP graphics card set 
to 1280x1024, 32 bit color. I haven't tested other settings.

So, I don't know what this means internally to the renderer, 
but this example does seem to flag a possible performance
issue.

Comment 9

[Marc Attinasi]

Updated summary for remaining issue - also, accepting to investigate.

Comment 10

[Marc Attinasi]

Sending to Kevin since the complaint is with repaints (see Additional Comments
From Ian Graham 2001-02-17 11:40). I just don't have time to look right now, and
paint problems are more up Kevin's alley anyhoo.

Comment 11

[Kevin McCluskey (gone)]

With today's build it is very snappy. No lag when bring the Mozilla window back
and forward. Marking WORKSFORME.

Comment 12

[Ian Graham]

I rechecked this on the March 8 build (2001030804), and found no 
change in performance -- the redraw speed is still _much_ slower
than it should be -- in particular, slower than on Nav4 or IE 5.
Moreover,  it is also much slower than the Mozilla redraw speed 
for the same document minus the background image.

I've created two much simplified (no CSS, less markup) cases 
to illustrate this:

http://www.java.utoronto.ca/NS5-bugs/redraw-bug-image.html
http://www.java.utoronto.ca/NS5-bugs/redraw-bug-noimage.html

The markup in both examples is trivial:

<html>
  <head>
    <title>Redraw speed bug</title>
  </head>
  <body background="100px.gif">
    <h1> A big long Heading with (possibly) a background image 
        for the entire page </h1>
   </body> </html>

the only difference being that the 'noimage' variant has no 
background image.

Viewing the two of these, and doing the tests I suggest (popping
Mozilla to foreground from behind a nother window, or grabbing
the right window border and resizing the window) should easily
show how the redraw is much slower when the background images
is present.

Comment 13

[Michael Coxon]

Slow redraw of positionable blocks (eg. DIV)
up to Mozilla 0.93

our observations are as follows:

1. we have an invisible positonable block with style.left=0px style.top=0px 
2. we then set its style.left, style.top properties to new values
3. we then set to visibiliy to visible.

on a largely empty page this process is quick (at least as quick as Netscape 
Navigator 4, Microsoft IE 4,5,5.5), but on a page with substantive content, 
this process becomes noticeably slower (taking at least a couple of seconds)

The calls to setting x,y co-ords is of the order of 10 milliseconds.

The time is taken up ouside of our code, presumably in redraw.

Comment 14

[Kevin McCluskey (gone)]

Build moving all existing future-P3 bugs to future-P4.

Comment 15

[Ian Graham]

It's been a while since this was last looked at ... so I had a quick look at 
this with a 0.9.8 build.  The redraw speed seems quite zippy now - much better 
than my original bug reports would imply. 

Looks like this bug may have closed itself, thanks to the many improvements 
that've taken place since August 2001.

I'll leave open for now, and check with the next build. If it's still good,
I'll close.

Comment 16

[Ian Graham]

Ok, I've rechecked this with nightly build 2002022209, with the following
conclusions (on Win98 - 450MHZ P3 16Mb 3dfx Voodoo3 3000D AGP card)

1. Redrawing with the original example 
http://smaug.java.utoronto.ca/NS5-bugs/posn-bug.html (absolutely positioned div
with semi-transparent background on top of a page with a background) is now
substantially faster than IE 5.5. So performance is quite acceptable, although
someone might want to compare with IE 6. 

2. Basic background redrawing (example
http://www.java.utoronto.ca/NS5-bugs/redraw-bug-noimage.html) is acceptably fast
but is noticeably slower than on IE 5.5 -- rapidly resizing a window shows
visible delay in painting the (white) background.

So, I don't know if I should close this bug, or leave it open to track layout
performance issues??  

Comment 17

[Kevin McCluskey (gone)]

Resolving WFM.