As I discovered in code investigations on Friday and in emailing webkit-dev today, when creating the master baseline pngs in the WebCore svn, the containing scrollview is done with Cocoa.
This triply screws us. Take a look at the actual/expected scrollbars for
css1/basic/inheritance.html (sideways for space; expected on top):
[image: scroll.png]
Screw #1: The colors are off (actual is just slightly darker). Why? It could
be a ColorSync issue, or perhaps Cocoa draws scrollbars just a bit
differently than Carbon (HITheme) does. It probably wouldn't be too
difficult to discover why, but that's work that still leaves us with...
Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes
scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a
"viewsize" value related to the physical size of the scrollbar. The precise
formula Cocoa uses to turn the view size into its proportion value is
unknown and would either have to be coaxed out of Apple or
reverse-engineered. But even if you could fix both of these screws, you'd
have to deal with...
Screw #3: WebCore (as used in the baselines) only uses Cocoa scrollbars for
the containing scrollviews. Any interior scrollbars are drawn using
ScrollbarThemeMac (Carbon, HITheme, etc). (We use ScrollbarThemeMac for all
scrollbars.) So even if we were able to tweak ScrollbarThemeMac to draw
scrollbars to exactly match the Cocoa scrollbars, that would break them
matching all the internal ones.
The only conclusion I can reach is that rebaselining is the only sane option
here.
Avi
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
<<inline: scroll.png>>
