Performance problems with absolutely positioned inline element

RESOLVED WORKSFORME

Status

()

defect
P4
normal
RESOLVED WORKSFORME
20 years ago
17 years ago

People

(Reporter: ian.graham, Assigned: kmcclusk)

Tracking

({perf})

Trunk
Future
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: WORKSFORME?, )

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).
Assignee: peterl → troy
Component: Style System → Layout
Status: NEW → ASSIGNED
Summary: Incorrect formatting of absolutely positioned inline element → {css2} Incorrect formatting of absolutely positioned inline element
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Using 12/2 build, verified fixed
Keywords: css2
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...
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 ]
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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...
QA Contact: chrisd → ian
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?
Assignee: troy → attinasi
Status: REOPENED → NEW
Keywords: css2perf
Summary: {css2} Incorrect formatting of absolutely positioned inline element → Incorrect formatting of absolutely positioned inline element
Whiteboard: WORKSFORME?
I'll download a newer build this weekend, and let you know.
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.
Updated summary for remaining issue - also, accepting to investigate.
Status: NEW → ASSIGNED
Summary: Incorrect formatting of absolutely positioned inline element → Performance problems with absolutely positioned inline element
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.
Assignee: attinasi → kmcclusk
Status: ASSIGNED → NEW
With today's build it is very snappy. No lag when bring the Mozilla window back
and forward. Marking WORKSFORME.
Status: NEW → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → Future
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Build moving all existing future-P3 bugs to future-P4.
Priority: P3 → P4
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.
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??  
Resolving WFM.
Status: REOPENED → RESOLVED
Closed: 19 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.