> On 22 Jul 2016, at 5:30 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jul 22, 2016, at 00:08 , Graham Cox <graham....@bigpond.com> wrote: >> >> If the thread building images never goes faster than once per second, the >> time to draw the image is a fraction of that - I’m sure 60fps is achievable, >> so making the thread wait for the drawing to be done isn’t going to hold it >> up significantly. > > (I’ve done something like this, though it was a couple of years ago, so the > same performance characteristics cannot be assumed.) > > With the sequence: > > worker thread -> NSBitmapImageRep -> main thread -> window > > not even 24 fps was achievable, for anything but fairly small images (say, > less than one quarter of a 21-inch non-Retina screen). That’s because a > bitmap image rep isn’t the internal representation of anything, so there > always a copy or two, along with a possible pixel format translation, and a > colorspace mapping.
A possible optimisation there would be to use -[NSView bitmapImageRepForCachingDisplayInRect:] which returns a rep that matches the backing store format and colorspace, so copying is fast. That might put more strain on the renderer code though, which has to deal with the format it finds, not one it created. > OTOH, I’m not sure 60fps is being asked for, unless that comes from your > special knowledge of what the app does. It was less than 1 fps per worker > thread, and if there are 60+ worker threads, there are likely other > performance issues as well. > It’s not being asked for - 1fps is the fastest. But I meant that if the drawing time is in the 60fps ballpark, then that part isn’t going to hold up the 1fps worker thread significanty. I *think* (correct me if I’m wrong Trygve) that there’s only one such worker thread. > On 22 Jul 2016, at 5:19 PM, Trygve Inda <cocoa...@xericdesign.com> wrote: > > This is how it works now, but we are running into a rare deadlock situation > where the main thread asks the worker thread to end (and waits until it does > so) while the worker thread is waiting for the image to be displayed. If the window has a imageRep property that is (atomic, copy) you shouldn’t run into a deadlock where the window tries to terminate the thread and it happens to be calling that method at the time. If you go with Roland’s suggestion, it doesn’t need to be copy, it can simply be strong. But make it atomic, as the property will need to be accessed from both the main and the worker threads and the rep must be in a viable state at both times. —Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
