Canvas memory issues and performance

[Scott Palmer]

On 2013-01-02, at 5:35 PM, joe andresen <joseph.andresen at oracle.com> wrote:

> So why not process the commands?
> 
> I think it would be tough to know when to process them and when to leave them alone.

The simple solution is to process them always and leave the optimization to the app developer like has already been suggested ("you should not send commands to the Canvas if it is not visible")

> Canvas is different then the other nodes in the scene graph in the sense that it could, not 100% of the time but sometimes, want to be processed when not visible, but generally when a node is not visible you do not want to process(render) it.

I understand, but it is also not like other nodes in the sense that if it does not process it queues commands indefinitely and you can run out of memory.  Which is worse? Processing when not visible, or running out of memory?  At some point the producer must block and let the consumer catch up.  Leaving the Canvas command queue unbounded is a disaster waiting to happen... I know, it already happened to me :-)

> And yes, we could add hints to help, but that leads to a slippery slope of adding a bunch of API that doesn't pull its own weight (A term Rich often uses). There was a similar request here a couple weeks ago about adding an LCD hint in canvas.

Yes, I agree. I was just using it as an example while pointing out that an optimization in Canvas to "know" when it can discard the unprocessed commands is not simple in my case.  But now that I think about it, that was probably a misunderstanding on my part.  All I am doing is calling setPixels on the entire Canvas via a PixelWriter.  As I understand it, setPixel is not the same as drawing over top of what is on the Canvas already, it's a complete replacement of the pixel data.  that means it should be possible to optimize such that all previous drawing commands are discarded, as you suggested.  I think that would solve the problem.  Then the command queue would only ever have one instruction in it in my case - "replace everything".

> Lastly, remember that canvas is a node, if you have a background color in your app, you could put the canvas node in a group and render a rectangle the size of the canvas that is the same color as the background in front of it, and i think that will cause it to keep updating (not tested). you could then fade in and out your rectangle when you want the canvas to be visible again. just a thought.

That doesn't fit my use case, but I get the idea.

Regards, 

Scott


> As for the media stuff, maybe a media guy can comment.
> 
> -Joe