Comments on: Are You Kidding Me? http://blog.vlad1.com/2008/02/15/are-you-kidding-me/ Look, it's a tagline! Fri, 04 Jul 2008 00:57:09 +0000 http://wordpress.org/?v=2.5.1 By: Boris http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-449 Boris Tue, 19 Feb 2008 09:21:14 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-449 It looks like the "don't block on flushes" thing that went in today reduced the chrome overhead a good bit.... It looks like the “don’t block on flushes” thing that went in today reduced the chrome overhead a good bit….

]]> By: vladimir http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-425 vladimir Sun, 17 Feb 2008 21:41:33 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-425 So, using NSScroller can be done, but there doesn't seem to be any way to programatically set the state of the various buttons. NSScroller has the nice advantage of being able to render into transformed contexts, which HITheme can't seem to do, but the buttons thing is a showstopper. Anyway, it also does the syscalls, so no real gain there. However, to be clear, the syscalls aren't the performance issue here. They're just ridiculously unnecessary. So, using NSScroller can be done, but there doesn’t seem to be any way to programatically set the state of the various buttons. NSScroller has the nice advantage of being able to render into transformed contexts, which HITheme can’t seem to do, but the buttons thing is a showstopper. Anyway, it also does the syscalls, so no real gain there.

However, to be clear, the syscalls aren’t the performance issue here. They’re just ridiculously unnecessary.

]]> By: Boris http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-423 Boris Sun, 17 Feb 2008 21:02:42 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-423 JB, the Cocoa thing here is NSScroller. See Colin's comments on why it's not being used. JB, the Cocoa thing here is NSScroller. See Colin’s comments on why it’s not being used.

]]> By: Xin Zhang http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-422 Xin Zhang Sun, 17 Feb 2008 20:39:36 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-422 So in OS X, under what condition, a process can change its EUID? So in OS X, under what condition, a process can change its EUID?

]]> By: JB http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-421 JB Sun, 17 Feb 2008 18:55:50 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-421 Well looking in /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h * HIThemeDrawTrack() * * Summary: * Draw a themed track item. * * Discussion: * Used to draw any tracked element including sliders and scroll * bars. * * Mac OS X threading: * Not thread safe I think threads are "where it's at" -- why use old Carbon calls? Does Firefox not want to be Cocoa for any particular reason? Well looking in /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

* HIThemeDrawTrack()
*
* Summary:
* Draw a themed track item.
*
* Discussion:
* Used to draw any tracked element including sliders and scroll
* bars.
*
* Mac OS X threading:
* Not thread safe

I think threads are “where it’s at” — why use old Carbon calls? Does Firefox not want to be Cocoa for any particular reason?

]]> By: Fred http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-411 Fred Sat, 16 Feb 2008 13:34:36 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-411 Wow, that's a whole bunch of context switches it's doing there. No wonder it's so slow: IIRC, OSX isn't exactly known for its high performance on that task. Wow, that’s a whole bunch of context switches it’s doing there. No wonder it’s so slow: IIRC, OSX isn’t exactly known for its high performance on that task.

]]> By: An interested party http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-406 An interested party Sat, 16 Feb 2008 06:57:03 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-406 While this doesn't fix your immediate issue with the call being slow, you should still file a bug with Apple on what you're seeing. http://developer.apple.com/bugreporter/ While this doesn’t fix your immediate issue with the call being slow, you should still file a bug with Apple on what you’re seeing.

http://developer.apple.com/bugreporter/

]]> By: Colin Barrett http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-405 Colin Barrett Sat, 16 Feb 2008 06:30:13 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-405 It gets worse! There *is no NSCell for NSScroller*. There's a way to direct the rendering of NSScroller into an offscreen buffer (NSView's displayRectIgnoringOpacity:inContext:), which I looked into, but NSScroller itself is a bit busted. Getting proper metrics out of it was just as bad as HIThemeDrawTrack, and of course broken in different ways. For a 300% performance hit and getting rid of ridiculous syscalls, it might be worth figuring NSScroller's mysteries. It also might be worth filing a radar. Perhaps it's actually a bug in Apple's code, ha ha? It gets worse! There *is no NSCell for NSScroller*. There’s a way to direct the rendering of NSScroller into an offscreen buffer (NSView’s displayRectIgnoringOpacity:inContext:), which I looked into, but NSScroller itself is a bit busted. Getting proper metrics out of it was just as bad as HIThemeDrawTrack, and of course broken in different ways.

For a 300% performance hit and getting rid of ridiculous syscalls, it might be worth figuring NSScroller’s mysteries. It also might be worth filing a radar. Perhaps it’s actually a bug in Apple’s code, ha ha?

]]> By: Smokey Ardisson http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-404 Smokey Ardisson Sat, 16 Feb 2008 05:56:53 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-404 I can't say the whole thing is sane, but calling into preferences to check for changes is "reasonable," since the scrollbar should change style and behavior when the user changes either the "next page vs. jump-to-here" pref or the arrow-position (which native scrollbars do, but which our themed scrollbars do not do at all--bug 389775--or properly--bug 377439) and the theme and highlight/selection colors (bug 122000). That said, it seems like a saner API design would have been to make all of HITheme APIs listen for change notifications and only react then instead of calling to see what's going on every single call :-P I can’t say the whole thing is sane, but calling into preferences to check for changes is “reasonable,” since the scrollbar should change style and behavior when the user changes either the “next page vs. jump-to-here” pref or the arrow-position (which native scrollbars do, but which our themed scrollbars do not do at all–bug 389775–or properly–bug 377439) and the theme and highlight/selection colors (bug 122000).

That said, it seems like a saner API design would have been to make all of HITheme APIs listen for change notifications and only react then instead of calling to see what’s going on every single call :-P

]]> By: Rob http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-403 Rob Sat, 16 Feb 2008 05:24:34 +0000 http://blog.vlad1.com/2008/02/15/are-you-kidding-me/#comment-403 This is the classic bad news, good news story with Shark. The bad news is the bug or overhead you found, the good news is how fast you were able to characterize it. This is the classic bad news, good news story with Shark. The bad news is the bug or overhead you found, the good news is how fast you were able to characterize it.

]]>