> On Nov 14, 2017, at 8:37 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
>> I’m not super into graphics, but my gut feeling is that, if you care about 
>> optimization details like whether pixmaps are being copied, you should 
>> really be using a lower-level graphics API than UIImage, which is mostly a 
>> cheap-and-cheerful convenience layer for apps that just need to splat a few 
>> PNGs into their GUI.
> 
> Well, then let me rephrase it as "unnecessary copies." In this case, I 
> (currently) need to manipulate the pixels to generate a new image. I will be 
> moving this to a Metal 2 filter soon enough, but for pre-iOS 11 users, I'd 
> still like to use as little memory as possible (we use a lot of memory in our 
> app).

One person’s un-necessary is another’s necessary. As Jens says UIImage is 
supposed to be the simple ‘most of the time’ API.

If the image is not drawn yet I believe the code listed earlier that works in a 
playground will return bytes to the compressed data anyway (png, jpg) so you 
won’t be able to preform ‘simple’ manipulation of that data.

If you are planning on moving to a metal shader then I’d say do that now. 
You’ll have complete control over how buffers are moved around with that API. 

If you are trying to debug your algorithm before committing it to a metal 
shader then you shouldn’t worry about memory constraints IMO.

If it’s debugging you are doing:

Make a data big enough to hold the decompressed image (size.x * size.y * 4 
bytes per pixel for rgba32, if you are using extended color space then you’d 
use more memory, I’m not positive about the details)
Make a context with this new data as the backing store
Draw your image.cgImage into that context
Now your data has the decompressed color data
Debug your algorithm

Metal 2 vs Metal is an interesting bifurcation point. I guess it could depend 
on what you are doing but I’d expect that almost anything you could do to 
filter an image in Metal 2 you could do in Metal.

Hope this helps.

TTFN,

-bd

> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com <mailto:rm...@latencyzero.com>
> 
> 
> _______________________________________________
> 
> 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/bdudney%40mac.com
> 
> This email sent to bdud...@mac.com

_______________________________________________

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

Reply via email to