> 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 m
>
> 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 * i
> 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 =
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
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
> ran
>
> 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 (in
> 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::Re
> 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
> 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
> threa
> 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
> th
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
> :
>
11 matches
Mail list logo
