Closed Bug 417612 Opened 16 years ago Closed 16 years ago

Mac native scrollbar drawing is huge performance hit

Categories

(Core :: Widget: Cocoa, defect, P1)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: vlad, Assigned: vlad)

References

Details

(Keywords: perf) 

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.
Keywords: perf
This was essentially resolved by bug 418311.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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.