Interesting, and surprising. Have you spoken to the #webkit folks
about this? Hyatt was the one that did all this re-factoring, maybe
this is expected, or not. I'd drop him an email directly if you can't
get anything out of #webkit.
On Fri, Sep 4, 2009 at 5:17 PM, Avi Drissman<a...@google.com> wrote:
> Speculation here (while I'm not 100% convinced I'm 99.44% there), but...
>
> Scrollbar thumb size has always been fuzzy. On the original Mac there was no
> way to specify the thumb size, and even today HIThemeDrawTrack (which is the
> most modern Mac theme-drawing API) has a parameter |viewsize| which is
> under-specified. While the theory is to make
>
> thumb : track :: view : doc size
>
> the Mac scrollbar code passes in the page scroll size for the viewsize
> parameter. You can see the code in ScrollbarThemeMac for details, but as an
> example, for LayoutTests/css1/basic/inheritance.html, the WebCore Scrollbar
> that had values visible size = 600, total size = 724 turned into:
>
> scrollbar size: 15x585 (we lose 15px to the growbox)
> min: 0
> max: 124
> viewsize: 560 (visible size of 600 - cAmountToKeepWhenPaging; see
> ScrollView::updateScrollbars)
>
> Now the scrollbar isn't 560/585 (96%) of the track so it's not clear where
> the thumb size (as drawn) is coming from. But that's not the problem.
>
> The problem is that I was trying to track down the same numbers for the
> reference images so I could see where the metrics were diverging. And I
> couldn't.
>
> I got DumpRenderTree from WebCore loading in GDB, but breakpoints in
> ScrollbarThemeMac.mm wouldn't hit. Nor would breakpoints in Scrollbar.cpp or
> ScrollView.cpp. In desperation I breakpointed on HIThemeDrawTrack. And that
> didn't hit either.
>
> What did hit was -[NSScroller drawRect:] at this damning backtrace:
>
> #0 0x96143759 in -[NSScroller drawRect:]
> #1 0x9605fbf8 in -[NSView _drawRect:clip:]
> #2 0x9605e6ef in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #3 0x9605ea86 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #4 0x9605ea86 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #5 0x9605ea86 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #6 0x9605ea86 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #7 0x9605ea86 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:]
> #8 0x9605d045 in -[NSView
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #9 0x96145385 in -[NSNextStepFrame
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #10 0x960594ab in -[NSView
> _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
> #11 0x95f99e7b in -[NSView displayIfNeeded]
> #12 0x00011ab4 in -[FrameLoadDelegate webView:didFinishLoadForFrame:] at
> FrameLoadDelegate.mm:207
>
> That's why the scrollbars are different. I thought that they'd moved from
> using the Cocoa scroll code in WebCore, but it doesn't seem so.
>
> Options:
> 1. Tweak ScrollbarThemeMac to generate values that make HIThemeDrawTrack
> draw identically to Cocoa (or fork it; same diff)
> 2. Rebaseline all images that only involve scrollbar diffs without mercy.
>
> Avi
>
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
