[Customdrawn] VMG. attn Felipe

[Felipe Monteiro de Carvalho]

On Thu, Apr 5, 2012 at 10:28 AM, Giuliano Colla
<giuliano.colla at fastwebnet.it> wrote:
> GTK: works fine. Not so smooth as desirable, but quite acceptable.

That's what I distribute for Linux at the moment.

> CD: It doesn't move. Stuck at the upper left corner of the screen, as if
> mouse position were always [0,0]. Either it doesn't receive mouse position,
> or it gets a wrong window position. Or both.
> Now I have a lot of work to do, but ASAP I'll investigate further. Most
> likely, it will point to what is still unimplemented in CD X11.

Good idea! Indeed GetCursorPos is not implemented for X11!

Implemented in rev 36571 =)

Now we can see the motion graphic going.

> BTW. I've implemented a first quick and dirty SmartPaint option, to avoid
> repainting the window if nothing has changed. It looks promising, but again
> I have no time to send a clean diff.

I already implemented this once purely on the frontend code, but it
was not effective and had bugs, so I dropped it. Indeed in the backend
side this could be done in a much more efficient way, it could send
the buffered native image.

But again: Make absolute sure that you are verifying if the window did
not change it's size. If it did, you need to invalidate the entire
form and rebuild the native image.

But this optimization is only useful in platforms which keep sending
us unnecessary repaint messages: X11 and Windows. Android and Cocoa
only request a repaint if really indispensable. Cocoa/Android buffers
our window and will not request a new image if you just partially
cover a window. This optimization will diminish CPU usage but the user
will probably not notice any difference in the VMG. Making the
painting itself faster is what is needed for motion graphics.

-- 
Felipe Monteiro de Carvalho