310591 - hidden elements drawn unnecessarily (S5 slideshows hang/beachball) (AppKit NSView drawing)

Status: RESOLVED WONTFIX

(Core :: Widget: Cocoa, defect)

Description

[Wevah (Nate Weaver)]

Go to the above URL. Try to go to the next slide. Hang!

Comment 1

[Simon Fraser [no longer active]]

The slideshow works by twiddling visibility: style on a bunch of <div>s between
hidden and visible, so we have a lot of widgets in the hierarchy for elements
that are hidden.

The problem is that in Cocoa widget, NSViews corresponding to the the widgets of
those nsViews all live in the NSView hierarchy, and AppKit is telling us to
redraw those views outside of Gecko's drawing loop. So we spend huge amounts of
time calling UpdateWidget() on widgets that should be being drawn at all.

This is a serious Cocoa widget issue. We are going to have to circumvent
AppKit's view drawing mechanism to fix this (which I believe Safari has already
had to do). We have other reasons to have to do this too (see bug 187435).

We could possible work around the problem if we can short-circuit the drawRect:
for a "hidden" widget, if there's a way to get that information in the widget code.

Comment 2

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

*** Bug 337839 has been marked as a duplicate of this bug. ***

Comment 3

[Simon Fraser [no longer active]]

Josh is going to have to deal with this in cocoa widgets.

Comment 4

[Håkan Waara]

(AIUI, display:hidden elements are not even in the view hierarchy, so I doubt they are a problem. visibility:hidden are still there though.)

Comment 5

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

You mean display:none.

I am working on a plan to eliminate all but the top-most widget of a window. That will fix this, I think.

Comment 6

[Stuart Parmenter]

Does this still happen?

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Why are we creating more than one platform widget for the content area in this case?  It seems like that's what we should try to fix/remove, even if roc's full patch for one topmost widget doesn't make it.

Comment 8

[Håkan Waara]

(In reply to comment #7)
> Why are we creating more than one platform widget for the content area in this
> case?  It seems like that's what we should try to fix/remove, even if roc's
> full patch for one topmost widget doesn't make it.
> 

I always wondered that as well.

If you stop in the debugger and check a ChildView's subviews and superview in gdb on runtime (try for example: print-object [self superview], print-object [self subviews] etc -- it'll print out lots of useful things) - there were always a big hierarchy of views with the same size. N

ote that this was when I was regularly still debugging the code, which means 2-3 months ago.

So if I had a tab with size X, I could normally also have a bunch of subviews with size X, and even those could have subviews with the same size. If we can optimize that (or fix the bugs!) I think it'll speed up the browser a lot.

Comment 9

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

The slides are position:fixed so we create a widget for each one on branch.

On trunk, we don't. And indeed, I'm not seeing a problem on trunk.

Comment 10

[Wevah (Nate Weaver)]

To true; I don't either, anymore. Changing to branch(?).

Comment 11

[Boris Zbarsky [:bzbarsky]]

As a branch bug, this is WONTFIX.  As a trunk bug this is WORKSFORME (or FIXED if you find when we stopped giving fixed-pos elements widgets).

Please resolve as desired.