High Level Toolkit -- is it obsolete or not?

  • I'm porting an application from Carbon to Cocoa.  There are a few things in it that I'm having problems finding the cocoa equivalent.

    The app is a music education product for kids.  They have to tap the rhythm on the spacebar or the mouse button in parts of the program -- i.e. precise timing is very important.  In the carbon version, I use GetMouse(), GetButton(), GetKeys(), etc. inside an interrupt (PrimeTime()).

    I can use NSView functions mouseDown, keyDown, etc. but the timing is not always sufficiently precise.  This is especially true when the entire window is updated and

    I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.

    What puzzles me is that GetKeys() still exists in 10.6.  It is not deprecated.  It runs fine in 64bit mode.  Also, GetMouse() and GetButton() have updated equivalents as HiGetMousePosition() and GetCurrentEventButtonState().  These functions are part of the 'High Level Toolkit'.

    The Carbon64BitGuide.pdf explains how the carbon api's have been updated for 64 bit.  But I thought carbon was dead in 64 bit and Snow Leopard.  What is the deal?  Am I safe using these api's. Are we supposed to not use them?  Will they go away in 10.7?  Why do I read everywhere that carbon is dead and high level toolkit is dead?

    If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.

    Is there a way to poll the state of the hardware using cocoa api's instead of the carbon api's?

    (Please don't tell me how cocoa is great and carbon is for losers.  I'm on board with the cocoa thing.)

    Thanks,
    Joel
  • On Feb 22, 2010, at 11:53 AM, Joel May wrote:

    > I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.

    GetButton() [by which I think you actually mean Button()] - the Cocoa equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
    GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics equivalent (but could be wrong!). It's perfectly fine to continue using GetKeys().

    > Am I safe using these api's. Are we supposed to not use them?

    You are safe using these APIs. They are still supported. We recommend that you use Cocoa equivalents when available - so you could use +[NSEvent pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.

    > Will they go away in 10.7?

    No, because that would break many existing applications, and we place a high priority on not breaking existing applications.

    > Why do I read everywhere that carbon is dead and high level toolkit is dead?

    Because many people are misinformed. Apple no longer recommends Carbon for new application development - Cocoa is recommended for all new development - but Carbon is not being removed from the OS either, because that would break existing applications. The High Level Toolbox APIs will continue to be supported for 32-bit apps and some parts of HLTB will also still be supported for 64-bit in cases where there is no other 64-bit equivalent.

    > If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets.

    You'd have to ask Apple Developer Relations about that. I'm just a grunt engineer. :)

    -eric
  • On Feb 22, 2010, at 11:53 AM, Joel May wrote:

    > I'm porting an application from Carbon to Cocoa.

    Good idea.

    > The Carbon64BitGuide.pdf explains how the carbon api's have been updated for 64 bit.  But I thought carbon was dead in 64 bit and Snow Leopard.

    Some of the APIs are deprecated, some are not. If something is not deprecated and in 64-bit, then feel free to use it.

    The guide you mention sums it up:

    "Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit applications, but some APIs commonly used by Carbon applications are not. In particular, the APIs used to implement a Carbon user interface are generally available only to 32-bit applications. If you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface."

    APIs like the Carbon Event Manager are still available, but the interface-related APIs such as Window Manager, Menu Manager, etc are not.

    > I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.

    There are no equivalents of those functions in Cocoa. Even games use mouseDown/keyDown etc, and you know there's no one more whiny and picky than a gamer. :-)

    If you're really having problems with delayed events, then your main thread must be very busy. How big of a delay are you seeing? Perhaps you should optimize whatever is eating all of that time (put it on a separate thread)?

    > If High Level Toolkit is ok, then why doesn't it appear in the docs.

    Apple is annoyingly aggressive about purging "old" documentation, and its search capability on its website is horrible. At any rate, assuming you mean the Human Interface Toolkit, the general answer to why some of it is "OK" and some isn't is because some of it is deprecated and some of it isn't. It's as simple as that. HIT is composed of several APIs. Select methods in select APIs are available. It's not always "all or nothing" inclusion.

    I hope that helps,

    --
    Seth Willits
  • On Feb 22, 2010, at 12:53 PM, Joel May wrote:

    > I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.

    There aren't any. GetKeys() still works fine, though it has some annoying differences depending on the target CPU architecture. Also, you need to do this on the main thread, since neither GetKeys() nor Cocoa events are thread-safe.

    > The Carbon64BitGuide.pdf explains how the carbon api's have been updated for 64 bit.  But I thought carbon was dead in 64 bit and Snow Leopard.  What is the deal?

    No, Carbon is not dead. The only parts of Carbon that are dead are the drawing components of HIToolbox, along with some legacy stuff like ATSUI and FSSpec. GetKeys() is one of the survivors.

    > Am I safe using these api's.

    Yes, unless they have been deprecated. GetKeys() has not been deprecated.

    > Are we supposed to not use them?

    No, but polling is something you probably shouldn't do without a good reason.

    > Will they go away in 10.7?

    Highly unlikely.

    > Why do I read everywhere that carbon is dead and high level toolkit is dead?

    Because at least one influential news source ran an incorrect story a number of years ago that Carbon wasn't being updated for 64-bit at all, which is not true, but that hasn't stopped people from believing it.

    > If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.

    I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.

    > Is there a way to poll the state of the hardware using cocoa api's instead of the carbon api's?

    No. The Cocoa event system does not act until something happens. Don't be afraid of using Carbon in a Cocoa application. Sometimes it's the only way to do something.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:

    > On Feb 22, 2010, at 12:53 PM, Joel May wrote:
    >
    >> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.
    >
    > I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.

    For what it's worth, there's a "legacy reference library" link at the current reference library: https://developer.apple.com/legacy/mac/library/

    Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation > click Get next to Mac OS X Leopard Core Library.  That still has the documentation for a number of APIs like FSFindFolder.  There's also a legacy docset in there, but I haven't bothered to look at what it contains.

    Regards,
    Ken
  • Le 23 févr. 2010 à 13:08, Ken Thomases a écrit :

    > On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:
    >
    >> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
    >>
    >>> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.
    >>
    >> I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.
    >
    > For what it's worth, there's a "legacy reference library" link at the current reference library: https://developer.apple.com/legacy/mac/library/
    >
    > Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation > click Get next to Mac OS X Leopard Core Library.  That still has the documentation for a number of APIs like FSFindFolder.  There's also a legacy docset in there, but I haven't bothered to look at what it contains.
    >

    It contains everything you need when you search for "legacy" API (FSFindFolder is in it for instance). I'm often using it as I'm working with the C QuickTime API and some Carbon API too.

    If you download it, you don't need the Leopard docset.

    -- Jean-Daniel
  • On 2/23/10 12:19 AM, Nick Zitzmann said:

    >> The Carbon64BitGuide.pdf explains how the carbon api's have been
    > updated for 64 bit.  But I thought carbon was dead in 64 bit and Snow
    > Leopard.  What is the deal?
    >
    > No, Carbon is not dead. The only parts of Carbon that are dead are the
    > drawing components of HIToolbox (...)

    Even that's an exaggeration.  The HIThemeDraw... APIs are not
    deprecated, and they are the only way to draw bits of standard UI
    elements.  For example, I have a custom NSCell that uses HIThemeDrawTrack
    () to draw a customised slider.  There's no other way to do that.

    That said, stay away from any deprecated Carbon API.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On Tue, Feb 23, 2010 at 7:23 AM, Sean McBride <sean...> wrote:
    > Even that's an exaggeration.  The HIThemeDraw... APIs are not
    > deprecated, and they are the only way to draw bits of standard UI
    > elements.  For example, I have a custom NSCell that uses HIThemeDrawTrack
    > () to draw a customised slider.  There's no other way to do that.

    Though we should probably file enhancement requests to get CoreUI
    pushed up to public API...

    --Kyle Sluder
  • Hey Eric,

    This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I still have to support tiger and leopard, but I'll build a separate snow leopard version and #ifdef that call in there.

    I've had the heebie-jeebies about including the Carbon framework in my application.  But I'm cool with it now.

    Thanks,
    Joel

    On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:

    >
    > On Feb 22, 2010, at 11:53 AM, Joel May wrote:
    >
    >> I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.
    >
    > GetButton() [by which I think you actually mean Button()] - the Cocoa equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
    > GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics equivalent (but could be wrong!). It's perfectly fine to continue using GetKeys().
    >
    >> Am I safe using these api's. Are we supposed to not use them?
    >
    > You are safe using these APIs. They are still supported. We recommend that you use Cocoa equivalents when available - so you could use +[NSEvent pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
    >
    >> Will they go away in 10.7?
    >
    > No, because that would break many existing applications, and we place a high priority on not breaking existing applications.
    >
    >> Why do I read everywhere that carbon is dead and high level toolkit is dead?
    >
    > Because many people are misinformed. Apple no longer recommends Carbon for new application development - Cocoa is recommended for all new development - but Carbon is not being removed from the OS either, because that would break existing applications. The High Level Toolbox APIs will continue to be supported for 32-bit apps and some parts of HLTB will also still be supported for 64-bit in cases where there is no other 64-bit equivalent.
    >
    >> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets.
    >
    > You'd have to ask Apple Developer Relations about that. I'm just a grunt engineer. :)
    >
    > -eric
    >
  • Nick,

    Thanks for clarifying.  I've been uncomfortable with using Carbon.  My guts are more settled now.

    Question about NSThread seeing how GetKeys(), etc. are not thread safe:  If I increase the priority of the main thread, then move the view draw cgcontext updates to a lower priority thread, is that a good idea?  Will increasing the priority of the main thread reduce latency for getting the keypress and mouse inputs?  Does the OS actually honor this request?  Can I take the drawRect requests and pass the rectangle to the lower thread and update the view there?  Is this crazy?

    Non-thread safety of GetKeys() and Buttons():  If I call these in the wrong thread, can they crash the application?  Or is the damage limited to erroneous results?  Of course, we don't know and we should be good and not do it.  But I might get desperate.

    Thanks huge for your help.

    Joel

    On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:

    >
    > On Feb 22, 2010, at 12:53 PM, Joel May wrote:
    >
    >> I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.
    >
    > There aren't any. GetKeys() still works fine, though it has some annoying differences depending on the target CPU architecture. Also, you need to do this on the main thread, since neither GetKeys() nor Cocoa events are thread-safe.
    >
    >> The Carbon64BitGuide.pdf explains how the carbon api's have been updated for 64 bit.  But I thought carbon was dead in 64 bit and Snow Leopard.  What is the deal?
    >
    > No, Carbon is not dead. The only parts of Carbon that are dead are the drawing components of HIToolbox, along with some legacy stuff like ATSUI and FSSpec. GetKeys() is one of the survivors.
    >
    >> Am I safe using these api's.
    >
    > Yes, unless they have been deprecated. GetKeys() has not been deprecated.
    >
    >> Are we supposed to not use them?
    >
    > No, but polling is something you probably shouldn't do without a good reason.
    >
    >> Will they go away in 10.7?
    >
    > Highly unlikely.
    >
    >> Why do I read everywhere that carbon is dead and high level toolkit is dead?
    >
    > Because at least one influential news source ran an incorrect story a number of years ago that Carbon wasn't being updated for 64-bit at all, which is not true, but that hasn't stopped people from believing it.
    >
    >> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.
    >
    > I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.
    >
    >> Is there a way to poll the state of the hardware using cocoa api's instead of the carbon api's?
    >
    > No. The Cocoa event system does not act until something happens. Don't be afraid of using Carbon in a Cocoa application. Sometimes it's the only way to do something.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
  • You don't have to build a separate version. Just test for method availability at runtime:

    if ([NSEvent respondsToSelector:@selector(pressedMouseButtons)])
    return [NSEvent pressedMouseButtons];
    else
    // do it the old way.

    Le 23 févr. 2010 à 23:18, Joel May a écrit :

    > Hey Eric,
    >
    > This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I still have to support tiger and leopard, but I'll build a separate snow leopard version and #ifdef that call in there.
    >
    > I've had the heebie-jeebies about including the Carbon framework in my application.  But I'm cool with it now.
    >
    > Thanks,
    > Joel
    >
    >
    >
    > On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:
    >
    >>
    >> On Feb 22, 2010, at 11:53 AM, Joel May wrote:
    >>
    >>> I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.
    >>
    >> GetButton() [by which I think you actually mean Button()] - the Cocoa equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
    >> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics equivalent (but could be wrong!). It's perfectly fine to continue using GetKeys().
    >>
    >>> Am I safe using these api's. Are we supposed to not use them?
    >>
    >> You are safe using these APIs. They are still supported. We recommend that you use Cocoa equivalents when available - so you could use +[NSEvent pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
    >>
    >>> Will they go away in 10.7?
    >>
    >> No, because that would break many existing applications, and we place a high priority on not breaking existing applications.
    >>
    >>> Why do I read everywhere that carbon is dead and high level toolkit is dead?
    >>
    >> Because many people are misinformed. Apple no longer recommends Carbon for new application development - Cocoa is recommended for all new development - but Carbon is not being removed from the OS either, because that would break existing applications. The High Level Toolbox APIs will continue to be supported for 32-bit apps and some parts of HLTB will also still be supported for 64-bit in cases where there is no other 64-bit equivalent.
    >>
    >>> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets.
    >>
    >> You'd have to ask Apple Developer Relations about that. I'm just a grunt engineer. :)
    >>
    >> -eric
    >>


    -- Jean-Daniel
  • Hey Ken,

    I never actually used that preference before.  Dumb me.  I'm adding leopard docs now.

    Thanks,
    Joel

    On Feb 23, 2010, at 6:08 AM, Ken Thomases wrote:

    > On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:
    >
    >> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
    >>
    >>> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.
    >>
    >> I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.
    >
    > For what it's worth, there's a "legacy reference library" link at the current reference library: https://developer.apple.com/legacy/mac/library/
    >
    > Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation > click Get next to Mac OS X Leopard Core Library.  That still has the documentation for a number of APIs like FSFindFolder.  There's also a legacy docset in there, but I haven't bothered to look at what it contains.
    >
    > Regards,
    > Ken
    >
  • On Feb 23, 2010, at 3:30 PM, Joel May wrote:

    > Question about NSThread seeing how GetKeys(), etc. are not thread safe:  If I increase the priority of the main thread, then move the view draw cgcontext updates to a lower priority thread, is that a good idea?  Will increasing the priority of the main thread reduce latency for getting the keypress and mouse inputs?

    Two words: Schrödinger's Cat. :) You won't know until you observe.

    > Does the OS actually honor this request?

    Yes, you can change a running thread's priority using NSThread. I've never had to change a main thread's priority, though.

    > Can I take the drawRect requests and pass the rectangle to the lower thread and update the view there?

    No; in all classes except for NSButton and NSProgressIndicator (and any other classes that use the old, private heart-beat API), you do threaded drawing by turning on concurrent drawing in the view. You can only do this in Snow Leopard & later, and it's not a good idea to try this unless you know for a fact that it supports thread-safe drawing. IKImageBrowserView, for example, will freeze if you turn on concurrent drawing.

    Also, it's been my experience that concurrent drawing is currently useless if you need to flush multiple updates to multiple views at once, because concurrent drawing changes flush immediately instead of at the same time as everything else, which could look a little strange. I have a bug open on this...

    > Is this crazy?

    Maybe.

    > Non-thread safety of GetKeys() and Buttons():  If I call these in the wrong thread, can they crash the application?  Or is the damage limited to erroneous results?

    The results are most likely undefined and could change between OS releases or even individual trials. I wouldn't try if the header says it's not thread-safe.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Oh yeah.  I've actually already done that with some other cocoa calls.  I forgot.  I have deploy sdk = 10.4 and base sdk = 10.5 (will change to 10.6).
    Thanks,
    Joel

    On Feb 23, 2010, at 4:30 PM, Jean-Daniel Dupas wrote:

    > You don't have to build a separate version. Just test for method availability at runtime:
    >
    > if ([NSEvent respondsToSelector:@selector(pressedMouseButtons)])
    > return [NSEvent pressedMouseButtons];
    > else
    > // do it the old way.
    >
    >
    >
    > Le 23 févr. 2010 à 23:18, Joel May a écrit :
    >
    >> Hey Eric,
    >>
    >> This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I still have to support tiger and leopard, but I'll build a separate snow leopard version and #ifdef that call in there.
    >>
    >> I've had the heebie-jeebies about including the Carbon framework in my application.  But I'm cool with it now.
    >>
    >> Thanks,
    >> Joel
    >>
    >>
    >>
    >> On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:
    >>
    >>>
    >>> On Feb 22, 2010, at 11:53 AM, Joel May wrote:
    >>>
    >>>> I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version.  I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.
    >>>
    >>> GetButton() [by which I think you actually mean Button()] - the Cocoa equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
    >>> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics equivalent (but could be wrong!). It's perfectly fine to continue using GetKeys().
    >>>
    >>>> Am I safe using these api's. Are we supposed to not use them?
    >>>
    >>> You are safe using these APIs. They are still supported. We recommend that you use Cocoa equivalents when available - so you could use +[NSEvent pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
    >>>
    >>>> Will they go away in 10.7?
    >>>
    >>> No, because that would break many existing applications, and we place a high priority on not breaking existing applications.
    >>>
    >>>> Why do I read everywhere that carbon is dead and high level toolkit is dead?
    >>>
    >>> Because many people are misinformed. Apple no longer recommends Carbon for new application development - Cocoa is recommended for all new development - but Carbon is not being removed from the OS either, because that would break existing applications. The High Level Toolbox APIs will continue to be supported for 32-bit apps and some parts of HLTB will also still be supported for 64-bit in cases where there is no other 64-bit equivalent.
    >>>
    >>>> If High Level Toolkit is ok, then why doesn't it appear in the docs.  If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets.
    >>>
    >>> You'd have to ask Apple Developer Relations about that. I'm just a grunt engineer. :)
    >>>
    >>> -eric
    >>>

    >
    > -- Jean-Daniel
    >
    >
    >
    >
  • OK.  I'm agreeing with you about not doing bad stuff.

    Thanks for the info about drawing in a different thread.  I won't waste my time and sanity.  I guess I need to figure out how to speed up the drawing instead and keep it in the main thread.

    I've switched from QuickDraw to Quarz, and performance has actually gotten worse.  After reading this post:

    http://www.kaourantin.net/2010/02/core-animation.html

    I'm thinking about switching the quartz code to CoreAnimation.  I need to blit an offscreen bitmap to the screen.  I'm hoping CoreAnimation will do it faster.  I haven't looked at the CoreAnimation API yet.

    Thanks,
    Joel

    On Feb 23, 2010, at 4:49 PM, Nick Zitzmann wrote:

    >
    > On Feb 23, 2010, at 3:30 PM, Joel May wrote:
    >
    >> Question about NSThread seeing how GetKeys(), etc. are not thread safe:  If I increase the priority of the main thread, then move the view draw cgcontext updates to a lower priority thread, is that a good idea?  Will increasing the priority of the main thread reduce latency for getting the keypress and mouse inputs?
    >
    > Two words: Schrödinger's Cat. :) You won't know until you observe.
    >
    >> Does the OS actually honor this request?
    >
    > Yes, you can change a running thread's priority using NSThread. I've never had to change a main thread's priority, though.
    >
    >> Can I take the drawRect requests and pass the rectangle to the lower thread and update the view there?
    >
    > No; in all classes except for NSButton and NSProgressIndicator (and any other classes that use the old, private heart-beat API), you do threaded drawing by turning on concurrent drawing in the view. You can only do this in Snow Leopard & later, and it's not a good idea to try this unless you know for a fact that it supports thread-safe drawing. IKImageBrowserView, for example, will freeze if you turn on concurrent drawing.
    >
    > Also, it's been my experience that concurrent drawing is currently useless if you need to flush multiple updates to multiple views at once, because concurrent drawing changes flush immediately instead of at the same time as everything else, which could look a little strange. I have a bug open on this...
    >
    >> Is this crazy?
    >
    > Maybe.
    >
    >> Non-thread safety of GetKeys() and Buttons():  If I call these in the wrong thread, can they crash the application?  Or is the damage limited to erroneous results?
    >
    > The results are most likely undefined and could change between OS releases or even individual trials. I wouldn't try if the header says it's not thread-safe.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
  • On Feb 23, 2010, at 4:35 PM, Joel May wrote:

    > Thanks for the info about drawing in a different thread.  I won't waste my time and sanity.  I guess I need to figure out how to speed up the drawing instead and keep it in the main thread.

    How often does your app flush its changes? If it's more than 30 f/s, then you're wasting redraws, and either need to disable beam sync, or cut back on the animation. You can use Quartz Debug to find out, and control the beam sync feature.

    Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off by default in Leopard & Snow Leopard, but it ought to work on most Macs. Again, you can experiment with this using Quartz Debug.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Nick,

    I'm using [NSView setNeedsDisplayInRect: r] and [NSView drawRect: r], so I'm not explicitly flushing and that's not goofing things up.  Beam-sync is related to flushing, I think.  I don't know how to turn it on or off programmatically and it does not appear in QuartzDebug -- I think it was removed in Snow Leopard or the newest XCode.  It might be renamed to AutoFlush drawing.

    However, I've found that I was not using the right CG function:  I was using CGContextDrawTiledImage()
    and should have been using CGContextDrawImage().  In my early testing I came to the mis-conclusion that CGContextDrawTiledImage() was faster.  It is actually about twice as slow.  I was jumping between machines and not being methodical about my testing.

    I've redone speed tests and now if I don't stretch the window, the screen update is fine on my new iMac.  If I do stretch to full screen,  CGContextDrawImage() takes about 80 ms and CGContextDrawTiledImage() takes about 140ms.

    Then I turned on QuartzGL (which I had never heard of until your email, thanks) with
    HIWindowSetBackingLocation(windowRef, kHIWindowBackingLocationVideoMemory).

    Now, CGContextDrawImage() takes 4ms or less to update the entire screen.  This is beautiful.

    I still need to test on my Tiger, PPC mac.  I'm thinking screen updates with Quartz will be a problem there, but I don't know yet.  I might have to use a separate executable with QuickDraw.  I use copybits in my own dirty rectangle handling in Carbon code. [NSView drawRect: r] seems to coalesce all the dirty rectangles into one big rectangle that also contains a lot of area that is not dirty.  My old code has smaller, non-overlapping dirty rectangles updated with copybits which should be more efficient.

    Conclusion:

    * Quartz is actually sufficiently speedy to update the screen, at least on a new mac.
    * QuartzGL is great, esp when stretching the image.
    * Not sure about Tiger (no QuartzGL) or older machines yet.  Might need to stay with QuickDraw/copybits.

    Thanks for your help.  I would have wasted a lot of time with CoreAnimation, which I don't need for this project.

    Joel

    On Feb 23, 2010, at 5:50 PM, Nick Zitzmann wrote:

    >
    > On Feb 23, 2010, at 4:35 PM, Joel May wrote:
    >
    >> Thanks for the info about drawing in a different thread.  I won't waste my time and sanity.  I guess I need to figure out how to speed up the drawing instead and keep it in the main thread.
    >
    > How often does your app flush its changes? If it's more than 30 f/s, then you're wasting redraws, and either need to disable beam sync, or cut back on the animation. You can use Quartz Debug to find out, and control the beam sync feature.
    >
    > Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off by default in Leopard & Snow Leopard, but it ought to work on most Macs. Again, you can experiment with this using Quartz Debug.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
  • Never call -drawRect: directly.  It is a Template Methods i.e. "Don't call us; we'll call you."  (Note: there might be some exceptions that prove the rule.)

    As of Leopard and possibly sooner, individual dirty rectangles are available through the - getRectsBeingDrawn:count: method if you use it within the implementation of -drawRect:.  Use - (void)getRectsBeingDrawn:count: for more detail beyond the automatically coalesced rectangle passed into -drawRect:.

    - (void)getRectsBeingDrawn:(const NSRect **)rects count:(NSInteger *)count

    Parameters
    rects
    On return, contains a list of non-overlapping rectangles defining areas to be drawn in. The rectangles returned inrects are in the coordinate space of the receiver.

    count
    On return, the number of rectangles in the rects list.

    On Feb 26, 2010, at 9:30 AM, Joel May wrote:

    > Nick,
    >
    > I'm using [NSView setNeedsDisplayInRect: r] and [NSView drawRect: r], so I'm not explicitly flushing and that's not goofing things up.  Beam-sync is related to flushing, I think.  I don't know how to turn it on or off programmatically and it does not appear in QuartzDebug -- I think it was removed in Snow Leopard or the newest XCode.  It might be renamed to AutoFlush drawing.
    >
    > However, I've found that I was not using the right CG function:  I was using CGContextDrawTiledImage()
    > and should have been using CGContextDrawImage().  In my early testing I came to the mis-conclusion that CGContextDrawTiledImage() was faster.  It is actually about twice as slow.  I was jumping between machines and not being methodical about my testing.
    >
    > I've redone speed tests and now if I don't stretch the window, the screen update is fine on my new iMac.  If I do stretch to full screen,  CGContextDrawImage() takes about 80 ms and CGContextDrawTiledImage() takes about 140ms.
    >
    > Then I turned on QuartzGL (which I had never heard of until your email, thanks) with
    > HIWindowSetBackingLocation(windowRef, kHIWindowBackingLocationVideoMemory).
    >
    > Now, CGContextDrawImage() takes 4ms or less to update the entire screen.  This is beautiful.
    >
    > I still need to test on my Tiger, PPC mac.  I'm thinking screen updates with Quartz will be a problem there, but I don't know yet.  I might have to use a separate executable with QuickDraw.  I use copybits in my own dirty rectangle handling in Carbon code. [NSView drawRect: r] seems to coalesce all the dirty rectangles into one big rectangle that also contains a lot of area that is not dirty.  My old code has smaller, non-overlapping dirty rectangles updated with copybits which should be more efficient.
    >
    > Conclusion:
    >
    > * Quartz is actually sufficiently speedy to update the screen, at least on a new mac.
    > * QuartzGL is great, esp when stretching the image.
    > * Not sure about Tiger (no QuartzGL) or older machines yet.  Might need to stay with QuickDraw/copybits.
    >
    > Thanks for your help.  I would have wasted a lot of time with CoreAnimation, which I don't need for this project.
    >
    > Joel
    >
    >
    > On Feb 23, 2010, at 5:50 PM, Nick Zitzmann wrote:
    >
    >>
    >> On Feb 23, 2010, at 4:35 PM, Joel May wrote:
    >>
    >>> Thanks for the info about drawing in a different thread.  I won't waste my time and sanity.  I guess I need to figure out how to speed up the drawing instead and keep it in the main thread.
    >>
    >> How often does your app flush its changes? If it's more than 30 f/s, then you're wasting redraws, and either need to disable beam sync, or cut back on the animation. You can use Quartz Debug to find out, and control the beam sync feature.
    >>
    >> Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off by default in Leopard & Snow Leopard, but it ought to work on most Macs. Again, you can experiment with this using Quartz Debug.
    >>
    >> Nick Zitzmann
    >> <http://www.chronosnet.com/>
    >>

previous month february 2010 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
Go to today