In my plugin I implement various RenderContent subclasses, which use only Fields for storage. Every time I hover the mouse over such a texture or material in a list, or select it with the preview pane visible, I see that Rhino renders a new preview. I observe the same for native Rhino content.
This seems unnecessary, given that RenderContents have a hash – it seems like a preview should be stored and only re-rendered when the hash has changed. I believe this would help reduce the general sluggishness of rendering-related GUI in Rhino.
I’ve cobbled together something for this internally, for materials, in CreatePreview – basically, store a copy of the preview bitmap whenever NotifyIntermediateUpdate has been called, in a dictionary keyed by the preview args ID (so far, this appears to be usable as a hash of the overall preview scene & material), and then also check if a cached bitmap is available whenever CreatePreview is called. This helps greatly, since a new render is only performed when the ID has actually changed, with a cached version being used otherwise, even if the preview is still being rendered (i.e. my current logic is just: use cache if possible, otherwise render a preview when full quality is requested).
However it would be better if this were handled internally, for various reasons, e.g. I have to use ReadDocument to clear out the bitmap cache since there’s not enough context in CreatePreview, to know whether a given bitmap is unlikely to be used again.
For textures I did not find a way to do even this; the CreateTexture2dPreview override is called, but its args have only an image and size, so I don’t really understand the purpose of the override. Trying CreatePreview, I could be missing something, but I have not yet observed it to be called with RenderContentKind.Texture. And I believe it would not help to try to implement caching in texture evaluators, since the sluggishness appears to be due to the many omp threads used for evaluation, which would still be the case whether sampling a cached bitmap or not.
Rhino has more context to work with, and the ability to store private data on content instances, so not only would it be able to handle this for all clients transparently, but it could do a better job of it, as well.