You have no control over how the target consumer patch is going to handle rendering, or if it is going to override any GL state on texture unit 0, or for that Gluint texture ID. Just because you set an image to have a particular parameter does not mean downstream consumers cant change those values, or that intermediate image processing patches, be it GLSL or Core Image Units wont change the associated parameter, on the original or on its new resulting output texture.
Why not just tile where you need to tile, while rendering Are you rendering something in this patch (ie, consumer, writing vertex data to the GL Scene), or are you just tagging metadata on an input image and sending it back out and on its way? The internal QC image pipeline is probably going to change, as the runtime version is now 4.5 (and will most likely change in subtle ways in 5.0, etc). This is the whole reason the internal state mechanisms of QC are meant to be internal, so bugs can be fixed and isolated from 3rd party developers. Perhaps you relied on a bug, or unsupported behavior in 4.0, and now 4.5 has fixed internal bugs, resulting in different behavior? I dont know, and, strictly speaking neither *should* you, because this is internal to the QC runtime, and not for your eyes. How about explaining what you are trying to accomplish? Of course, I know, there are still things 3rd party plugins using vanilla API can't accomplish. That sucks, but it is stable, and does work as intended (except, you know, that whole port ordering issue, the execution time parameter bug and, well some other stuff, har). ;)
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
