Jim Graham wrote:
On 8/13/2015 12:33 PM, Kevin Rushforth wrote:
* Node caching was intended as a hint to the system to cache the result
of potentially expensive effects into a texture (which is rendered into
by the GPU) and re-render that texture when needed. Jim was suggesting
that an application might be able to use that mechanism to do something
other than its original purpose.
I'm not sure my suggestions were fully understood. I didn't mean to
imply that the node cache property and hints could be used as a
"render to texture and give me the texture" mechanism, but that many
cases where the developer might think "what I want is a mechanism to
render some scene into a texture so that I could do something with it"
really boil down to cases where sprinkling in a few setCache(true)
calls might achieve what they want more directly.
Yes, that is a more clear way to look at it.
In the end, we'd rather have a direct mechanism to have the developer
tell us what they want to have happen and then we might cache various
parts of the scene graph automatically in pursuit of that goal so that
the developer doesn't have to think about "well I know this is going
to perform badly so I want to start caching my own pixels". The node
cache property is sort of a request to "do that pixel caching thing
for me", but with limited scope. Sometimes, though, that limited
scope is exactly what the application needs.
My subsequent mail that gave a few examples of regrouping items with
effects and cache properties being set demonstrates how node caching
is intended to take care of these details for you...
Hopefully one of our enterprising app developers can try it and report
the results.
Thanks!
-- Kevin
...jim
