> I got a couple of questions related to these operations: > > - I understand that there are two ways to get to the pixeldata of an incoming > image - either CPU intensive (just as I am doing it), or GPU intensive (which > I am not doing right now as it seems more complicated) > Generally speaking, since I am not doing any transformation on the image > other than scaling it down, is there any potential speed gain in using the > GPU method (using a OpenGL Texture object if I am not mistaken)?
scaling on the GPU (if you don't care too much about scaling quality) will be much faster -- vImage does a lanczos resample, which is high quality but kinda expensive. The GPU can do bilinear out-of-the-box. You shouldn't do this yourself; just have an image resizer patch before you feed the input to your QC patch. > - the vImage_Buffers are set up so that I can call the "vImageScale_ARGB8888" > method of the Accelerator Framework. I am however not interested in any alpha > channel - my final pixeldata which is to be sent out over the wire must be 24 > bits (meaning RGB values, with no alpha). Is there any other (speedy) method > to scale down an incoming image just using 24 bit color or is > "vImageScale_ARGB8888" the fastest scaling operation there is? You should completely ignore trying to strip off alpha. having 4 components per pixel is what a lot of things are tuned for (vector units tend to be multiples of 2 or 4 elements wide), and trying to be clever with 3 channels generally just doesn't pan out unless you write a bunch of custom vector code yourself. > - what would happen if I would made the definition of the NSBitmapImageRep to > be 24 bit, no alpha? Would the scaling still work and produce correct images > (sorry, I can't test that for the moment, the LED wall is literally on the > other side of the world so that I cannot test it) > - finally, the most time consuming process is the reading out of the RGB > pixel values of my vImage_Buffer vDestBuffer which holds the scaled down > image. Since this is ARGB however, I must skip every 1st byte since I am not > interested in the alpha value, just RGB. Is there no quicker way to read out > the pixel data? I'm going to bail out of answering your questions at this point. What's the NSBitmapImageRep for? From the snippet below, it looks like you're leaking that object, but you're also not even really using it -- you want a struct. You shouldn't append data to the NSData like that; what you're doing is quite literally the second worst way to do that (the first-worst would be sourcing an NSData the same way into a destination NSData). You're sending a message per pixel. Despite what all the objc fanatics say about message send being fast, doing it per pixel is hideously wasteful. And for NSData, it's possible it drives a realloc() under the hood (because it doesn't know how much you're going to add, so it can't allocate the right size up front). And with realloc, it's possible you're going to pay a memcpy too. Per Pixel. So that's pretty bad. why not use malloc() to get a buffer of the right size (width * height * 3), write into the buffer, and then make an NSData out of the malloc'd block (since I assume you're using some kind of convenience library what wants an NSData to send stuff). make sure you free the buffer when you're done, and you'll skip millions of message sends, reallocs, and potential memcpys. per frame. so: scale on the GPU (unless the quality isn't good enough -- if that's the case, please ask, it's pretty easy to get better scaling out of the GPU at a nominal cost), and don't use NSData as your buffer machine. that should get a sizeable win. -- Christopher Wright [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
