Closed Bug 299742 Opened 19 years ago Closed 19 years ago

Page with clear:both and centered text redraws too much


(Core :: Layout, defect)

Not set





(Reporter: swan.turcotte, Assigned: roc)




(Keywords: perf, regression)


(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050620 Camino/0.9a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050620 Camino/0.9a1

there is an animated gif on apple website for the countdown of the 500,000th
song dowloaded and it bug camino.

Reproducible: Always

Steps to Reproduce:
1.go to and see by yourself (there is an animated gif that go crazy
there, just today touhgt

Actual Results:  
it frozed the GUI to crawl

Expected Results:  
I guess it shouldn't have frozed the GUI---- keep on the good work Pink!
works for me, i see the countdown but no ui freeze.
The count-up works fine for me, too. (It's also not a GIF; it's text changed via
We are using a nice 36% of my 1.25 Ghz G4 just for that page, auch. Using Quartz
debug you can see that we redraw the entire webpage, yes the freaking entire
webpage, each time the counter updates. So I can imageine on some older machines
this could cause so Major speed issues. Safari doesn't even take 5%cpu on that page.
Hi guys, sorry that I misinterpreted the problem. On my mac (g3 600 MHz 768 mo
RAM) Camino jump to up to 71% cpu usage and when I reported the problem I was on
a 333 mhz g3 but I Haven't checked the usage... nuff said!
on my iMac G3 500: Camino (2005070408 (v0.9a1+)) takes 100% CPU, becomes very
very slow on the UI (beachball), and even says "Application not responding" in
the dock.
Safari: works perfectly
Deer Park: 100% cpu, but I can still control the UI.

please change the title, because it's not an animated gif, it's Javascript.
Summary: really quick animated gif crashe Camino → Text-changed via javascript (force redraw of whole page + cpu go crazy)
So this is sort-of a dupe of bug 280982 (and its friend, bug 272954)?  Should it
be duped to the former?

We're starting to get a number of bugs where Camino is redrawing too often or
too much of the page too often...bug 280982, bug 272954, bug 293813 off the top
of my head.
Keywords: perf
Marking as duplicate of bug 280982, this has nothing to do with form fields or java.

*** This bug has been marked as a duplicate of 280982 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
uh, i only see one animated object in the view, so why would we dupe it to the
bug of inefficient redraw with two animated objects?

this seems like a different problem entirely. i suggest unduping until we know
for sure.
Reopening per comment 8.  I wasn't convinced it was a dupe of bug 280982,
either; similar, yes.

Hmm, there is the regular hot news ticker just above the countdown; it's an
animated gif.  But bug 280982 still claims only the rectangle bounding the two
elements gets redrawn, and Jasper says this is redrawing the entire page.
Resolution: DUPLICATE → ---
I'm not an expert in QuartzDebug like Jasper, but it's clear to me that Camino's
redrawing the entire page even when the animated gif has stopped animating (I've
got it set in user.js to display once).  Safari, by contrast, only is updating
the counter box when it redraws.
can someone figure out at what point this regressed?
(I was typing this when the bug was reopened)

this is NOT a duplicate of 280982.

This bug is also noticable in FireFox (Deer Park 1) so it's NOT Camino specific,
but Gecko specific.
Just use Quartz debug and visit with Firefox.

Oeps: it gets worse: this is a REGRESSION: in Firefox (... Gecko/20050511
Firefox/1.0.4) only the text gets updated, in Deer Park alpha 1 (Gecko/20050618)
the whole page gets updated, as witnessed in Quartz Debug.

I was just about to write what Stefan added; Fx is affected, too, but the
1.7/Aviary branch builds are fine.

I don't have any more time to chase this now, but the oldest Camino-Trunk I have
on hand, May 27, displays the problem.

I'm going to go ahead and confirm the bug and update the keywords, but I don't
know what Core component this belongs to, so someone else please move to the
right place.
Ever confirmed: true
Keywords: regression
one quick thing to this related to the quartz image landing? that
caused scrolling to repaint too much.
camino 20050307: only paragraph of text gets updated
camino 20050308: whole page gets updated

both from the "nighly builds"
I tracked it down to bug 281267.  roc, any idea how to fix this regression?
roc: ping?

We need a testcase in this bug. The apple page has changed.
Confirming that this happens in Deer Park too. Over to roc.
Assignee: pinkerton → roc
Component: Page Layout → Layout
Product: Camino → Core
Version: unspecified → Trunk
this is a (very) quick&dirty testcase.
Just activate Quartz debugger to flash yellow on screen update, and compare
Apple1.html with Apple2.html. 
The excess drawing is caused by the presence of the animated gif.
(In reply to comment #19)

> this is a (very) quick&dirty testcase.
> Just activate Quartz debugger to flash yellow on screen update, and compare
> Apple1.html with Apple2.html. 
> The excess drawing is caused by the presence of the animated gif.

There's more to it than that, though.  Apple1.html is just bug 280982.	

If I change the animated GIF into a static one, the entire page still redraws
when I sub in Stefan's revised counter script to my HTML complete archive of
the page.  (The only other thing I did was rename the JS that tries to contact

Um, I'm still getting the same Apple page, but attaching the zip just in case.
My "testcase" was to demonstrate the bug on Camino, and I begin to think it
shows bug 280982.

it's a LOT more complicated on DeerPark. My reduced Apple1.html shows ok (only
the changed elements gets a yellow flash), but on the original page it
flashes a lot more.
After some testing it's somehow related to the floated images before the
animated gif (the podcasting images), but with a twist: drawing is ok when I
hide the counter, but not when I show the counter.
animated gif(newsticker) + floated images = ok
animated gif(newsticker) + floated images + counter = not ok
animated gif(newsticker) + not-floated images + counter = ok, unless the
not-floated images is an animated gif!!

I begin to think that animated (or dynamic elements) redraw themself, their
containing element and somehow floated elements before them in the document tree.
it's all strange...
Summary: Text-changed via javascript (force redraw of whole page + cpu go crazy) → Page with clear:both and centered text redraws too much
Attached file Testcase
This testcase shows the problem (you'll need to use a tool like QuartzDebug to
show you what's redrawing).

The required conditions seem to be:
1. Body text is centered
2. There is a <div> with clear:both style
3. Something causes a reflow (like dynamically changing text).

In both Camino and DeerPark, the "Some text here" div is being reflowed and
redrawn as the counter changes.
Attached patch fixSplinter Review
This patch helps. Note that most absolute containers also have their own space
managers, in which case HasAnyFloats will be false and we don't need to worry
about what happens to our children with clearance.
Attachment #188515 - Flags: superreview?(dbaron)
Attachment #188515 - Flags: review?(dbaron)
Attachment #188515 - Flags: superreview?(dbaron)
Attachment #188515 - Flags: superreview+
Attachment #188515 - Flags: review?(dbaron)
Attachment #188515 - Flags: review+
Comment on attachment 188515 [details] [diff] [review]

Fixes fairly severe performance problem on pages with DHTML, absolute
positioning and 'clear'
Attachment #188515 - Flags: approval1.8b4?
Attachment #188515 - Flags: approval1.8b4? → approval1.8b4+
checked in
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.