Mac native scrollbar drawing is huge performance hit

RESOLVED FIXED

Status

()

Core
Widget: Cocoa
P1
normal
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: vlad, Assigned: vlad)

Tracking

({perf})

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

With the numbers that we have now that the nochrome tinderboxes are up, the Mac numbers are horrible with chrome compared to without:
          Normal     nochrome
MacOS X    1550        555
Win32       520        456

While looking into bug 328380 and going nuts trying to figure out what the perf difference was, I tried turning off native theme rendering (returning NS_OK at the start of DrawWidgetBackground).  For the testcase there, with native theme disabled, I was getting ~6500ms, which is roughly the 1.8 time on that testcase.  With native theme enabled, I get ~9900ms.  I was running that test in a 1200x1000 -chrome window, so the only native theme bits that should have been drawn were the button (which scrolls out of view) and the scrollbar.
Flags: blocking1.9+
I'm going to take this to dig.
Assignee: joshmoz → vladimir
Priority: -- → P1
This seems to be largely localized around the scrollbar drawing.  Not calling HIThemeDrawTrack gets back the performance.  This sort of makes sense, since scrollbars are visually complex.  Is there any reason why we might be drawing them more often now than we were with 1.8?  I may have to do a 1.8 build with a patch to see what kind of perf hit scrollbars were in 1.8.
Summary: Mac native theme is huge performance hit → Mac native scrollbar drawing is huge performance hit
Uhhh... on 1.8 we were using a native scrollbar widget on the mac.  In 1.9 we're not.
Probably not, that only makes us redraw the whole scrollbar when actual scrolling happens.

In bug 409083 I noticed that setting a breakpoint on HIThemeDrawTrack doesn't catch all scrollbar rendering. Is there a Cocoa NSCell-like way to draw scrollbars? Maybe it's faster? Check Webkit? I'd like to know what it is to help debug 409083...

BTW we use HIThemeDrawTrack to draw progress bars too...
See also bug 398137 and bug 407180, the former probably being a direct dupe.

I thought I'd seen Colin mention some drawing alternatives for scrollbars in another bug (maybe even a bug specifically on using other than HIThemeDrawTrack), but I can't seem to find it now.  All I can find is bug 54488 comment 44.
Duplicate of this bug: 398137

Updated

10 years ago
Keywords: perf
This was essentially resolved by bug 418311.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 9

10 years ago
I'm running a 20080224 build on OSX 10.5 and scrollbars are still slow. Bug #418311 didn't fix or improve this. Please reopen this (or my bug #398137)!
You need to log in before you can comment on or make changes to this bug.