very large image in QC, Limit?

I'm not sure about what the image limits are... I think they are different depending on gpu/cpu capabilities, but don't hold me to that.

One common way to handle really large textures is to tile them up ahead of time, or use some kind of process to do so first and keep them in a buffer, and composite each of the tiles back into the whole image... there was an interesting ongoing discussion about this on one of the apple developer lists recently (either the quartz or core animation list I think), and this was where the discussion lead to as the good solution.

The attached composition will tell you what your Composer installation can render up to in Quartz Composer.

Also see the following thread for offline rendering capabilities in Quartz Crystal.

http://kineme.net/Release/Production/QuartzCrystalmaximumrendersize .

See also the attached workaround - I'm not sure if I'm on the right lines with how I've approached 'solving' this problem you've posed, but I'm sure you'll let me know.

Actually on further experimentation, I can tell you that even using the immense image size you propose, this 'workaround' fails to result in much beyond a total blur mainly showing the predominant colour of the 80000 * 1080 image. However, dynamically resizing doesn't slow me down as much as you report, but it does result in a significant slow down to just below 30 fps.

I tried the the splicing approach george was suggesting, incl. preloading all slices into an image structure with jacascript.. looks promising (full 60+ fps) but needs a bit more work getting the mapping right for left and right scroll. thanks for you suggestions, cybero, i got the same 8xxx pixel texture size limit. might have to do with the amount of vram.

There's that GPU capability vs OS X version chart in Apple's developers docs. I can't find it right now, I'm pretty sure Vade has linked to it before. It's a table with coloured bar highlighting that runs horizontally then vertically — know the one I mean?

download OpenGL Extension Viewer, and search for MAX_TEXTURE_SIZE. On my gpu it is 16384 x 16384

So 80k/16 = roughly 5. Split your big picture in 5 and link 5 sprites together.

Looking more, it's also available from the OpenGL Info patch's max texture size output.

On this machine, it's 8192x8192, and there are 8 available texture units, before stuff starts falling back on cpu.

This isn't applicable (eg., it doesn't make sense for you to use this, it's for iOS), but this shows what I mean about using that methodology to get performance honed.

https://github.com/dhoerl/PhotoScrollerNetwork

Looking at the way that other systems/apps/frameworks handle this might give some ideas.

I'm the author of the PhotoNetworkScroller mentioned above. What that project does in essence is allow you to map an image of virtually unlimited size into a file, then grab small chunks of that file as needed to keep a CATiledLayer happy. That whole infastruture should work just fine on the Mac (I used pieces of that project earlier on the Mac myself - in Leopard).

I don't really know QC internals, but if you can leverage a CALayer into a QC composition (and I'm pretty sure you can) then what my project does should be of enormous value to you. On the phone, its hard to render a large image to a memory mapped file as there are limits to virtual memory, but on the Mac is should not be an issue.

Someone else has asked me to make a Mac version of my project, and I'll be glad to incorporate your monster image if you can put it somewhere online where I can pull it (like DropBox). Cannot promise short term response but it shouldn't take me more than a few weeks to get going.

https://github.com/dhoerl/PhotoScrollerNetwork

David

dhoerl at mac dot com

Typically there are 16 texture units (legacy/non-shader mode reports 8, because that's the standard -- GL_MAX_TEXTURE_IMAGE_UNITS is 16, but QC doesn't expose this). 8kx8k and 16kx16k are the normal size limits these days. (https://developer.apple.com/graphicsimaging/opengl/capabilities/)

The number of units is mostly irrelevant though - it's rare to have that be the limit. It's not the maximum number of textures one can have, but the maximum number of textures used simultaneously for a single drawing operation (e.g., inputs to a shader).

You probably know this, gtoledo, but I didn't want a casual reader to think that if they had 9 textures that things would fall over.

thanks for this clarifiaction.

"oh no he ditnt" ;-)

Sure, it's when dealing with one process, right? If a process calls more than the GL_MAX_TEXTURE_IMAGE_UNITS, it can work, it can fallback on CPU, or just not work and still fit spec? Can you clarify? That was my impression, but I don't know for sure.

That's the link I was trying to find on developer.apple.com. Thanks @cwright.

Be careful with what "calls" means, and how fallback works and doesn't.

If you have GL_TEXTURE0, 1, 2, 3 N - 1 (where n = GL_MAX_TEXTURE_IMAGE_UNITS enabled and bound with textures, it will work. It will throw a GL error if you try to bind GL_TEXTUREN or N+ whatever. This is unrelated to fallback (and won't trigger it, its simply an error to activate and bind to more units than you have available in hardware for the current renderer).

Texture size is also specific to the renderer, where for software its 16384 pixels, and hardware clearly depends on the GPU in question.

This works for me, with an image that is the size you request (80000x1080, tiff, uncompressed), at 60Hz, all in native QC..

My understanding is this is because QC loads images with Core Image, and Core Image automatically handles tiling for you, based on the hardware and renderer combination.

vade wrote:
My understanding is this is because QC loads images with Core Image, and Core Image automatically handles tiling for you, based on the hardware and renderer combination.

Huh, really? I thought it was Core Graphics. It doesn't make a CIImage, it makes a CGImage.

[CIImage image withCGImage:]

To be clear I meant Core Image handles tiling when necessary (you can't "load" an image with CI, I should have been more clear).

That said, looking at this again, I think QC and Core Graphics is totally cheating, and loading some sort of preview of my large image. Using a different large as hell image makes it clear its not loading the full quality version. Its doing something like Preview does, when it first loads, but it never seems to resolve to the crisp full res.

Perhaps the only method is to indeed manually chop it up.

http://kineme.net/forum/General/XcodeisnowanapphowdoesQCgetupdated#comme...

Any reason you seem to be taking that so personally?

Oh, I should have put a :-) I thought that was funny, I'd not seen it before... the meme seemed appropriate here as well.

I thought that little bit of wording was very Beckett like and also very funny.