299742 - Page with clear:both and centered text redraws too much

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Swan]

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 apple.com and see by yourself (there is an animated gif that go crazy
there, just today touhgt
2.
3.

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!

Comment 1

[Mike Pinkerton (not reading bugmail)]

works for me, i see the countdown but no ui freeze.

Comment 2

[Wevah (Nate Weaver)]

The count-up works fine for me, too. (It's also not a GIF; it's text changed via
JavaScript.)

Comment 3

[Jasper]

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.

Comment 4

[Swan]

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!

Comment 5

[stefan livens]

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.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 7

[Jasper]

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 ***

Comment 8

[Mike Pinkerton (not reading bugmail)]

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.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 11

[Mike Pinkerton (not reading bugmail)]

can someone figure out at what point this regressed?

Comment 12

[stefan livens]

(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 www.apple.com 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.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 14

[Mike Pinkerton (not reading bugmail)]

one quick thing to check...is this related to the quartz image landing? that
caused scrolling to repaint too much.

Comment 15

[stefan livens]

camino 20050307: only paragraph of text gets updated
camino 20050308: whole page gets updated

both from the "nighly builds"

Comment 16

[jhp (no longer active)]

I tracked it down to bug 281267.  roc, any idea how to fix this regression?

Comment 17

[Simon Fraser [no longer active]]

roc: ping?

We need a testcase in this bug. The apple page has changed.

Comment 18

[Simon Fraser [no longer active]]

Confirming that this happens in Deer Park too. Over to roc.

Comment 19

[stefan livens]

Attachment: test case for bug 299742

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.

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: HTML Complete + Stefan's Counter + static "ticker" 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
metrics.apple.com).

Um, I'm still getting the same Apple page, but attaching the zip just in case.

Comment 21

[stefan livens]

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 apple.com 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.
So:
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...

Comment 22

[Simon Fraser [no longer active]]

Attachment: 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.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

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.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 188515 [details] [diff] [review]
fix

Fixes fairly severe performance problem on pages with DHTML, absolute
positioning and 'clear'

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in