Re: Getting mouse clicks when the main loop is busy
Re: Getting mouse clicks when the main loop is busy
- Subject: Re: Getting mouse clicks when the main loop is busy
- From: Uli Kusterer <email@hidden>
- Date: Sun, 10 Nov 2013 13:21:39 +0100
On 08 Nov 2013, at 20:17, Graham Cox <email@hidden> wrote:
> If the file is small and can be read quickly, it really doesn’t make much difference either way whether it’s threaded or not. But if it’s a large file, there may be some time (even minutes) between clicking ‘Open’ in the NSOpenPanel and the document opening its window. During that time, there is no feedback whatsoever that anything is happening. It acts, for all intents and purposes, as if the ‘Open’ click was ignored.
Are you saying there’s no way to get the async document loading mechanism to open the empty document first, then asynchronously load the data into that window (giving you the opportunity to show partially loaded content or a progress indicator *inside* the document window)?
That’s what I would expect it to do. Open the document, then call the read method asynchronously, giving you behaviour as if it was a “revert”, effectively. I haven’t used the async loading API, but I’d expect there to be some oddly-named call that gives you such behaviour, or something implicit you’re doing wrong that keeps your document from appearing?
If that’s not the case, what I’d try is do less in the “read” call, and defer more to later. I.e. at first, load an NSData of the entire file or so, and maybe a preview TIFF if you have one, indicate success so your window gets opened. Once that is done, kick off a thread that post-processes the NSData and performs the actual loading, replacing the preview TIFF in the window with the actual vector drawings (or whatever is appropriate for your app).
The advantage of threading in this context would be
1) On modern, multi-core systems, each document gets its own core, so you get actual simultaneous parallel processing on faster machines.
2) If the user opens several files at once, they all show up faster, hopefully already partially useful, and the user can pick one of them to start working with, or e.g. already compare the start of two documents while the rest is still being laid out.
Your current approach may be faster on smaller Macs, but will be just as slow on 12-core Mac pros.
Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden