[img]http://s3-eu-west-1.amazonaws.com/stvle/a50ad09c890f752650d9b06e1934e801.png[/img]
It's actually done like that deliberately to fix a performance issue I had. The thing is that when small subsections of large in-memory images are drawn via CoreGraphics or GL (very common when using cached component images), then it's far more efficient to use the subimage technique, because otherwise the entire image has to be sent up to the GPU when most of it isn't needed. Annoying that you're having the exact opposite problem, but I'm not sure how that method could be made to please everyone.
...actually, the best solution would probably be to get rid of that method altogether. If it wasn't there, callers would have to decide whether they want to create their own subimage and draw it, or to call drawImageTransformed instead (which is what you should do to fix your performance problem).
performance or not, as it is juce doesnt render it at all!
what im thinking is that the OpenGLImage type is a bit clumsy. is there a way to achieve the same thing directly using the openGL classes like the frame buffer and texture class. I had a go, but couldnt figure out how to access the right shader program in the state without hacking into the implementation of these classes.
I agree that the GL image is a PITA, because it can only be created/deleted/used while a GL context is active. The correct solution, which I intend to do if/when I ever get chance, is to just make the GL renderer keep cached framebuffer copies of normal images when they're used, so that you don't have to worry about any of this crap.