Closed Bug 280982 Opened 20 years ago Closed 19 years ago

Redraw is inefficent when two or more animated elements are visible in the viewport.

Categories

(Camino Graveyard :: General, defect, P3)

PowerPC
macOS

Tracking

(Not tracked)

RESOLVED FIXED
Camino1.0

People

(Reporter: moz, Assigned: mikepinkerton)

References

()

Details

(Keywords: perf)

Attachments

(2 files)

When two or more animated elements (e.g., animated GIFs) are visible in the
viewport, the entire rectangle bounding the animated parts is redrawn, instead
of just the parts themselves. This can be seen easily in the linked testcase
using Quartz Debug (compare with Firefox, which does not have this problem).

This bug also appears to manifest with just one animation when the page is
scrolled with a scroll wheel; in this case, the entire viewport is redrawn
instead of just the animation and the page area that was just scrolled into view.

Much of this might be due to Cocoa combining drawing rects on non-opaque views,
but perhaps a workaround can be found.
Summary: Redraw is inefficent when two or more animated elements are inside of the viewport. → Redraw is inefficent when two or more animated elements are visible in the viewport.
Doesn't 10.2 have some new NSView updating methods that might help here?
I wonder if fixing this would help with typing in pages with animations?
Keywords: perf
Priority: -- → P3
It's probably very closely related.
*** Bug 287609 has been marked as a duplicate of this bug. ***
I've verified that [getRectsBeingDrawn:count:] in [ChildView drawRect:] does
return the 2 rects that need updating. Somewhere (maybe in cocoa?) something is
causing the union of those two rects to be flushed to the screen.
In addition to animated GIFs, there's another demonstration of this with JS(?)
animated text on the Gmail login page (no gmail account needed to see it):

https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&continue=https%3A%2F%2Fgmail.google.com%2Fgmail%3Fui%3Dhtml%26zy%3Dl&hl=en

Should this block 0.9?  The bug it blocks is approved for blocking 0.9 (will
both be fixed at once?)
Flags: camino0.9?
Depends on: 166932
*** Bug 297260 has been marked as a duplicate of this bug. ***
From what I can tell, even editing an email in Gmail triggers this.  The JS on
the front page (which is now changed) would cause near 100% CPU usage, but even
composing a message would cause (on a 1.8GHz G5 iMac) 1-2 second lags between
typing and echoing of *each character*.  THis makes Camino useless for Gmail. 
Note that this problem does not happen in Firefox.
(In reply to comment #8)
> From what I can tell, even editing an email in Gmail triggers this.

Typing issues are bug 272954, although the two are related.
Lot of people seem to have forgotten about this bug, eben while it's the most
obvious speed bumb we could get when fixed. I still think this is something we
should fix asap i possible do I'll be putting some priority on it.
Target Milestone: --- → Camino1.0
*** Bug 299742 has been marked as a duplicate of this bug. ***
*** Bug 299569 has been marked as a duplicate of this bug. ***
More and more websites start to use more and more animation crap because most
browsers can handle it. This needs to get fixed soon, users are suffering some
nasty stuff because of this.
Severity: normal → major
regarding bug 299742
I don't think it's ****, I think this Ajax stuff is pretty interesting: websites
don't have to update/load the whole page. 
Unfortunately: that's just what Camino does. (i know: reloading != redrawing)

Maybe there should be a META bug for these bugs, where al the excess drawing
bugs are put together. (bug 299742 (excess drawing thru JS), 272954 (excess
drawing in TEXTAREA), 280982 (excess drawing of too much of the page with
animated gif's)

Or change the title of this bug to include "dynamic elements" and "excess
drawing" (as this bug is referenced like in the description of bug 290234)

oh: this excess drawing (of bug 299742) is also visible in Deer Park, so we have
to mark bug 299742 as NOT a duplicate of this one.
camino 20050307: only paragraph of text gets updated
camino 20050308: whole page gets updated

both from the "nighly builds"
ignore previous post, should have been in bug 299742.
Sorry.
Can someone pin down a regression window for this (maybe look around 20050311).
This patch has 2 changing text divs. It does not suffer the unionized redraws,
suggesting that those are image-only, so affectged by the Quartz image drawing
(bug 245407).
I don't know how you are looking simon. But when I look with quartz debug I can
clearly see that one big rectangel including the two divs is painted and not 2
small rectagles of only the divs.
Ok well on the other hand Safari shows the same thing. So please tell me with
what I should look ;)
(In reply to comment #19)
> I don't know how you are looking simon. But when I look with quartz debug I can
> clearly see that one big rectangel including the two divs is painted and not 2
> small rectagles of only the divs.

You're right, I was too hasty. I see a unified update rect on 10.3 with Quartz
Debug.
Attached patch PatchSplinter Review
The CHBrowserView (which is the ancestor of all the gecko views) was using the
non-optimal view repainting, which caused the update area to be larger. This
fixes that, and fixes both image and text testcases.
Attachment #190079 - Flags: review?(joshmoz)
Comment on attachment 190079 [details] [diff] [review]
Patch

r=mark with preprocessor conditionals to avoid [self respondsToSelector:] and
fallback when MAC_OS_X_VERSION_MIN_REQUIRED >= 10.3
Attachment #190079 - Flags: review?(joshmoz) → review+
Checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Clearing the ? flag since this was fixed....
Flags: camino0.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: