> That's okay for a quick hack. In the case of a video preview surface, I will > be explicitly setting the value for every pixel from a ByteBuffer. You could > save the extra step of doing a rectFill or clearRect if you knew that every > pixel was about to be overwritten. It's a reasonable optimization.. but as a > fix for this issue it's still only a half-fix hack.
I wouldn't call it a hack, just an obvious optimization that would happen to help in this case. > "If pulses are not happening, we still need to remember these scribbles so we > can draw the right result." > > No. If pulses are not happening you need to block or force a pulse somehow. > Otherwise I don't see how having the unbounded queue is ever going to be 100% > reliable. I agree it would be better to render the thing. We still need a way to tell people that what they're doing isn't visible so they can stop their timer or whatnot to avoid wasted CPU cycles / battery drain. > Since we are talking about painting to the Canvas surface as opposed to > directly modifying the scene graph, why does the painting have to happen > "later" when a pulse occurs? It's not like you have any other thread writing > to the Canvas. Why can't the Platform thread actually *do* the scribbles,and > the pulse just refreshes the portion of the Canvas that is visible on the > screen? Is it some D3D/OpenGL multi-threading complication? No doubt drawing to the actual screen in this case won't work (since the surface is likely "lost"), but if we're doing double buffering then we should still be able to draw to the texture. There might be nasty details to work through (windows / graphics guys?). At the high level we short-cut out of doing a pulse if the window is not actually visible so we don't waste CPU resources, but from a high level it would be easy enough to keep track of whether we have dirty canvas' and need to render them anyway. I don't know about the low levels whether they would blow up. Richard
