• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Getting immutable UIImage data pointer without copy?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting immutable UIImage data pointer without copy?


  • Subject: Re: Getting immutable UIImage data pointer without copy?
  • From: Bill Dudney <email@hidden>
  • Date: Wed, 15 Nov 2017 07:38:10 -0800

> On Nov 14, 2017, at 8:37 PM, Rick Mann <email@hidden> 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
> email@hidden <mailto:email@hidden>
>
>
> _______________________________________________
>
> 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

_______________________________________________

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

References: 
 >Getting immutable UIImage data pointer without copy? (From: Rick Mann <email@hidden>)
 >Re: Getting immutable UIImage data pointer without copy? (From: Rick Mann <email@hidden>)
 >Re: Getting immutable UIImage data pointer without copy? (From: Jens Alfke <email@hidden>)
 >Re: Getting immutable UIImage data pointer without copy? (From: Rick Mann <email@hidden>)

  • Prev by Date: Re: Getting immutable UIImage data pointer without copy?
  • Next by Date: Re: Getting immutable UIImage data pointer without copy?
  • Previous by thread: Re: Getting immutable UIImage data pointer without copy?
  • Next by thread: Re: Getting immutable UIImage data pointer without copy?
  • Index(es):
    • Date
    • Thread