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

[GothicChess.Com]

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!

 

[MongoTheGeek]

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.

 

[GothicChess.Com]

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.

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.

 

[lazydog]

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.

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

 

[iSee]

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:
http://developer.apple.com/document...es.html#//apple_ref/doc/uid/TP40001474-110101

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