Re: Concurrent loading of images ?
> I would add, that for a long running process, open ended work, or task, I > would favor a thread. But for short and finite items I would favor > GCD/NSOperationQueue. > > Are you going to only load one image, the next image, in this concurrent > loading scenario? Or, will you be loading many images and caching them? No, just one (next) image. That will then get displayed about a minute later, at which point the image after that should get prefetched. > > I would imaging looking one or two ahead would be the choice. Yes, I am planning to look ahead just one image. That's why I thought a whole queue might be overdoing it for just one task that takes usually just a few milliseconds, and occasionally 1-2 seconds. But if you say that for such one-off tasks, an NSOperationQueue is better, I'll go with that approach. And thanks a lot to everybody for sharing their insights and hints. ___ 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
Re: Concurrent loading of images ?
> > Also, if you’re already getting a CGImageRef using > CGImageSourceCreateImageAtIndex, why not just set imgLayer.contents to the > CGImageRef? Good point . What I am doing right now is: NSImage * nsimage = [self convertToNSImage: img withOrientation: img_orientation]; CALayer * imgLayer= [CALayer layer]; imgLayer.contents = nsimage; The reason for that is that otherwise (IIRC) the EXIF orientation flags would not be heeded correctly by the CALayer. Is there a better way to achieve this? Best, G. ___ 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
Re: Concurrent loading of images ?
> Also, if you’re already getting a CGImageRef using > CGImageSourceCreateImageAtIndex, why not just set imgLayer.contents to the > CGImageRef? sorry, my previous response regarding this was incomplete. What I am doing is this, in order to get the EXIF orientation right: CIImage * image = [CIImage imageWithCGImage: imageRef]; CIImage * orientedimage = [image imageByApplyingOrientation: (CGImagePropertyOrientation) img_orientation]; NSCIImageRep * nsimgrep = [NSCIImageRep imageRepWithCIImage: orientedimage]; NSImage * nsImage = [[NSImage alloc] initWithSize: nsimgrep.size]; [nsImage addRepresentation: nsimgrep]; CALayer * imgLayer= [CALayer layer]; imgLayer.contents = nsImage; Still, is there a better way? Best regards, Gabriel ___ 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
Re: Concurrent loading of images ?
Again, thanks a lot for all the helpful hints. Before restructuring my code, I did a few timings, using a set of test images ranging in size from 30 through 300 MB. I used mach_absolute_time() for this experiment. And now, I am confused. These are the execution times I have found for some of the methods that I invoke in the process of loading and displaying the next image: CGImageSourceCreateWithURL: 0.4-1.4 millisec CGImageSourceGetStatus: 10-600 microsec CGImageSourceCopyPropertiesAtIndex: 0.8-9 millisec CGImageSourceCreateImageAtIndex:15 microsec convertToNSImage (*): 25 microsec imgLayer.contents = nsimage:1-5 microsec removeFromSuperlayer: 0.1 microsec addSublayer:5-10microsec (*): this is a wrapper method of mine that does a few calls to CIImage/NSImage/NSCIImageRep methods. Overall, none of the methods I invoke seems to incur a long execution time. Yet, there is a noticeable lag when my app switches from one image to the next one. I can tell because all layers have an animation assigned. Sometimes , there is even a stutter in the animation itself. But it doesn't seem like it makes sense at this point to load images in a concurrent/background dispatch queue, does it? So, I am confused: where is the lag coming from? Any ideas how I might be able to prevent the lag/stutter when loading and switching to big images? Best, G. ___ 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
Re: Concurrent loading of images ?
Have you profiled this? The first thing I would to is run that in Instruments. Georg > Am 9. May 2020 um 14:44 schrieb Gabriel Zachmann via Cocoa-dev > : > > Again, thanks a lot for all the helpful hints. > > Before restructuring my code, I did a few timings, using a set of test images > ranging in size from 30 through 300 MB. > I used mach_absolute_time() for this experiment. > And now, I am confused. > > These are the execution times I have found for some of the methods that I > invoke in the process of loading and displaying the next image: > > CGImageSourceCreateWithURL: 0.4-1.4 millisec > CGImageSourceGetStatus: 10-600 microsec > CGImageSourceCopyPropertiesAtIndex: 0.8-9 millisec > CGImageSourceCreateImageAtIndex:15 microsec > convertToNSImage (*): 25 microsec > imgLayer.contents = nsimage:1-5 microsec > removeFromSuperlayer: 0.1 microsec > addSublayer:5-10microsec > > (*): this is a wrapper method of mine that does a few calls to > CIImage/NSImage/NSCIImageRep methods. > > Overall, none of the methods I invoke seems to incur a long execution time. > Yet, there is a noticeable lag when my app switches from one image to the > next one. > I can tell because all layers have an animation assigned. > Sometimes , there is even a stutter in the animation itself. > > But it doesn't seem like it makes sense at this point to load images in a > concurrent/background dispatch queue, does it? > > So, I am confused: where is the lag coming from? > > Any ideas how I might be able to prevent the lag/stutter when loading and > switching to big images? > > > Best, G. > > ___ > > 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/georg.seifert%40gmx.de > > This email sent to georg.seif...@gmx.de ___ 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
Re: Concurrent loading of images ?
> > Try Instruments. Apple have written a measuring tool for a reason :) Thanks for the hint. I've done that. In the Heaviest Stack Trace, I am seeing functions like CA::Transcation::commit() CA::Render::copy_image(..) CI::recursive_tile(..) etc None of these functions seems to get invoked (indirectly) by any of my code. Instead, they all seem to be called (indirectly) by _CFRunLoopDoObservers (in the main thread). So, I feel a bit stumped. What can I do? It seems that somehow I need to make all this stuff happen in the background - but how? ___ 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
Re: Concurrent loading of images ?
> On May 9, 2020, at 08:51, Gabriel Zachmann via Cocoa-dev > wrote: > > >> >> >> Try Instruments. Apple have written a measuring tool for a reason :) > > Thanks for the hint. > > I've done that. > In the Heaviest Stack Trace, I am seeing functions like > CA::Transcation::commit() > CA::Render::copy_image(..) > CI::recursive_tile(..) > etc If an image is huge and/or highres, it’s naturally going to take more time to render. I’d experiment and see if pre-sizing images before passing them onto the layer will be more efficient. Probably not, but it seems like some parts of the various Mac image frameworks do a better job of scaling than others. Steve via iPad ___ 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
Re: Concurrent loading of images ?
> Time to learn some more about the frameworks you’re using then :) :-) > People have long dealt with this on iOS by doing tricks like first drawing > that image to a 1x1 bitmap on a worker thread before sending it on to the UI. Would that really make the background (worker) thread execute all that internal copying/decoding of images in the *background* thread? I am asking because, currently, all this stuff gets executed in the main thread invoked by some observer. And, after all, even a background thread eventually has to put the new image in the layer hierarchy, which, I fear, will cause the heavy lifting to be done by the main thread, again. Can you point me to some resources ? or examples that have solved this issue? Best regards, Gabriel > You have to do something along these lines (as far as I’m aware) to prompt > the first decode of the image to happen. After that, drawing it will be much > faster. > > Mike. ___ 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
Re: Concurrent loading of images ?
> On May 9, 2020, at 12:13, Gabriel Zachmann via Cocoa-dev > wrote: > > Would that really make the background (worker) thread execute all that > internal copying/decoding of images in the *background* thread? > > I am asking because, currently, all this stuff gets executed in the main > thread invoked by some observer. > And, after all, even a background thread eventually has to put the new image > in the layer hierarchy, which, I fear, will cause the heavy lifting to be > done by the main thread, again. The point is, yes, the worker thread would be handling the image manipulation to resize it to something that lets the main drawing thread work more efficiently. Steve via iPad ___ 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
Re: Concurrent loading of images ?
> On May 9, 2020, at 07:41, Gabriel Zachmann wrote: > > >> Also, if you’re already getting a CGImageRef using >> CGImageSourceCreateImageAtIndex, why not just set imgLayer.contents to the >> CGImageRef? > > sorry, my previous response regarding this was incomplete. What I am doing is > this, in order to get the EXIF orientation right: > > CIImage * image = [CIImage imageWithCGImage: imageRef]; > CIImage * orientedimage = [image imageByApplyingOrientation: > (CGImagePropertyOrientation) img_orientation]; > NSCIImageRep * nsimgrep = [NSCIImageRep imageRepWithCIImage: > orientedimage]; > NSImage * nsImage = [[NSImage alloc] initWithSize: nsimgrep.size]; > [nsImage addRepresentation: nsimgrep]; > CALayer * imgLayer= [CALayer layer]; > imgLayer.contents = nsImage; > > Still, is there a better way? > > Best regards, Gabriel I’m not at my computer now, but if you load the image using the thumbnail option it will give you a properly oriented image. I’ll check the specific options when I get home and can look at the code. If you’re using CIImage anyway, you can render it back to a CGImageRef with a bitmap context, and that can be done in a separate thread as well. Then you have a rendered bitmap ready to assign to your CALayer contents property. Jim Crate ___ 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
Re: Concurrent loading of images ?
The last time I used layers to draw images it made a HUGE difference if the image was pixel perfect matching the size of the layer. If the image needed scaling, it was quite slow (I had really tiny images, but a lot of them). g > Am 9. May 2020 um 19:16 schrieb Steve Mills via Cocoa-dev > : > >> On May 9, 2020, at 12:13, Gabriel Zachmann via Cocoa-dev >> wrote: >> >> Would that really make the background (worker) thread execute all that >> internal copying/decoding of images in the *background* thread? >> >> I am asking because, currently, all this stuff gets executed in the main >> thread invoked by some observer. >> And, after all, even a background thread eventually has to put the new image >> in the layer hierarchy, which, I fear, will cause the heavy lifting to be >> done by the main thread, again. > > The point is, yes, the worker thread would be handling the image manipulation > to resize it to something that lets the main drawing thread work more > efficiently. > > Steve via iPad > > ___ > > 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/georg.seifert%40gmx.de > > This email sent to georg.seif...@gmx.de ___ 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
