IDE: XCode, Language: C, API: Carbon, Question: Timed Splash Screens

Discussion in 'Mac Programming' started by GothicChess.Com, Jun 20, 2007.

  1. GothicChess.Com macrumors regular


    Apr 6, 2007
    Philadelphia, PA
    Now that the engine in my checkers program is nearly complete, and the opening book generator is active and building itself, it is time to get the GUI into focus.


    Here is a brief explanation:

    On startup, I have to read some very large files of precomputed wins into a large buffer. It will allow the checkers program to announce a win from a distance of 371 plies, or 186 moves (for the winning side.) As the program searches, it may encounter any of the 10 trillion positions I have precomputted, allowing it to announce its victory from very early on in the game should the player stumble in the least.

    Having said that, the initial first load takes up to 8 minutes, depending on your system. What I am trying to do is show a splash screen with a progress bar while this is going on.

    I am having no luck, even though I allocate the window storage, make the call to DrawPicture(), all chronologically before I begin reading the large checkers databases.

    All I get is the "busy" cursor, a blank window, 8 minutes of a rectangular version of a "polar bear in a snow storm", followed by a very nice image of the splash screen and a 100% progress bar indicator.

    No doubt, the OS is prioritizing the heavy disk reading to window drawing. Is there any way around this?

    Thanks in advance!
  2. MongoTheGeek macrumors 68040


    Sep 13, 2003
    Its not so much where you are as when you are.
    You need to go multithreaded. The solution is to load the databases on a background thread and let the window load up on the main thread.

    When the background thread has finished running the background thread can run performOnMainThreadSelector:Object: to stop your progress bar.
  3. GothicChess.Com thread starter macrumors regular


    Apr 6, 2007
    Philadelphia, PA
    Well, that would work if I was using Cocoa and C++, but I am not, I am using Carbon and C.

    I have done progress bars on time-intensive loading operations under OS 9 so I don't see why periodic calls from within the code execution cannot merely pause to paint a window on demand.
  4. lazydog macrumors 6502a

    Sep 3, 2005
    Cramlington, UK
    I think you can still fork() a child process if you're using Carbon. I may be wrong … I've done a quick test and it seems to work ok.

    b e n
  5. iSee macrumors 68040


    Oct 25, 2004
    Threads are still the way to go for something like this.
    In OS 9 the window painting system was much simpler and designed to be driven by the app. Under OS X the OS wants to drive repainting windows.

    Anyway, here are all your threading options:

    DON'T use the Carbon Thread Manager.
    You probably want "Carbon Multiprocessing Services" threads or POSIX Threads.

Share This Page