The best way would be to use vImage and make a vImage_Buffer from a CGImageRef.
look at the documentation for vImageBuffer_InitWithCGImage() vImage might end up doing the image conversion you need to do as a bonus. the vImage API is kind of different, but once you figure out how to use it, you will notice how powerful it really is. Vince > On Nov 14, 2017, at 8:37 PM, Rick Mann <rm...@latencyzero.com> wrote: > > > >> On Nov 14, 2017, at 20:18 , Jens Alfke <j...@mooseyard.com> wrote: >> >> >> >>> On Nov 14, 2017, at 8:11 PM, Rick Mann <rm...@latencyzero.com> wrote: >>> >>> Maybe, at least for the bonus question. The bigger question is around the >>> copy. >> >> Where pixmaps live is a pretty complex issue — ideally they live in the >> GPU’s address space as textures so they can be blitted efficiently, and >> that’s often (depending on your hardware) not accessible to the CPU at all. >> But there’s a lot of logic in CoreGraphics and the underlying graphics >> engines to shuffle the pixmaps back and forth so software can read and write >> them. >> >> Another factor is that the pixmap may be rescaled or translated into >> different color spaces to optimize rendering it. So there may not exist a >> default rendering of it at the time you request one, meaning CG will >> generate a new pixmap for you. (Also, I dunno about UIImage, but NSImage >> supports image formats like PDF that don’t have a native pixmap >> representation at all.) >> >> 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). > > > -- > 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/demarco%40apple.com > > This email sent to dema...@apple.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
