Re: [swift-users] Making a copy of an UnsafePointer

2017-11-15 Thread Rick Mann 
Ah, never mind. I was indexing well past the end of the buffer. D'oh.

> On Nov 15, 2017, at 00:48 , Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 15 Nov 2017, at 04:16, Rick Mann via swift-users  
> wrote:
> 
>> Is UnsafeMutablePointer<> not memory managed?
> 
> It is not.  Specifically, the code you posted creates a copy of the data and 
> then never destroys it.
> 
> If I were in your shoes I’d construct a `Data` value from the unsafe pointer 
> and then pass that around.
> 
> let source = Data(bytes: inSourceBuffer, count: inSourceBufferLength)
> self.queue.async {
>let size = source.count
>source.withUnsafeBytes { (p: UnsafePointer) in
>self.foo(data: p, length: size)
>}
> }
> 
> The main drawback to this is that you have to jump through the hoops to 
> access the data unsafely.  It might be easier to recast your consumer (the 
> `foo(…)` method) in terms of `Data`.  That’s what I generally do when I work 
> with foreign APIs like this, that is, keep the data in ‘Swift space’ and only 
> deal with foreign types at the boundaries.
> 
> Whether that makes sense here really depends on the specifics of your 
> program.  For example, if your program has lots of this boundary code, it 
> might be nicer to just stick with the foreign type.  Or build a specific 
> wrapper that makes it easier to do this conversion.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users


-- 
Rick Mann
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting immutable UIImage data pointer without copy?

2017-11-15 Thread Vince DeMarco 
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  wrote:
> 
> 
> 
>> On Nov 14, 2017, at 20:18 , Jens Alfke  wrote:
>> 
>> 
>> 
>>> On Nov 14, 2017, at 8:11 PM, Rick Mann  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 
> 
> 
> ___
> 
> 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

Re: Getting immutable UIImage data pointer without copy?

2017-11-15 Thread Steve Christensen 
On Nov 14, 2017, at 8:37 PM, Rick Mann  wrote:
> 
>> On Nov 14, 2017, at 20:18 , Jens Alfke  wrote:
>> 
>>> On Nov 14, 2017, at 8:11 PM, Rick Mann  wrote:
>>> 
>>> Maybe, at least for the bonus question. The bigger question is around the 
>>> copy.
>> 
>> Where pixmaps live is a pretty complex issue…
> 
> 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, if you're trying to work with pixel data in a buffer then how about 
something like this? It delivers premultiplied 8-bit RGBA pixels to manipulate. 
I believe the only buffer of any significant size should be the pixel buffer 
for the bitmap context. (The docs say that makeImage() is only supposed to do a 
buffer copy on write so it should be using the context's buffer.)

func manipulateImage(_ image: UIImage) -> UIImage
{
let imageBounds = CGRect(origin: CGPoint.zero, size: image.size)
let width   = Int(imageBounds.size.width)
let height  = Int(imageBounds.size.height)
let colorSpace  = CGColorSpaceCreateDeviceRGB()
let bitmapInfo  = CGBitmapInfo(rawValue: 
CGImageAlphaInfo.premultipliedLast.rawValue)

if let bitmap = CGContext(data: nil,
  width: width,
  height: height,
  bitsPerComponent: 8,
  bytesPerRow: 0,
  space: colorSpace,
  bitmapInfo: bitmapInfo.rawValue)
{
bitmap.draw(image.cgImage!, in: imageBounds)

let bytesPerRow = bitmap.bytesPerRow
var buffer  = bitmap.data!.bindMemory(to: UInt8.self, capacity: 
(bytesPerRow * height))

for row in 0 ..< height
{
var pixel = buffer

for _ in 0 ..< width
{
var red   = pixel[0]
var green = pixel[1]
var blue  = pixel[2]
var alpha = pixel[3]

processPixel(, , , )

pixel[0] = red
pixel[1] = green
pixel[2] = blue
pixel[3] = alpha

pixel += 4
}

buffer += bytesPerRow
}

if let processedCGImage = bitmap.makeImage()
{
return UIImage(cgImage: processedCGImage)
}
}

return nil
}

___

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: Getting immutable UIImage data pointer without copy?

2017-11-15 Thread Bill Dudney 

> On Nov 14, 2017, at 8:37 PM, Rick Mann  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 
> 
> 
> ___
> 
> 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