Andrew Sayman

Federico talks about throttling repaints on motion events.

This seems like a solution that will only solve the problem for motion events. Maybe that's the only time it applies, but I wonder if another approach would work better.

Specifically, rather than taking repaint() as a command, it simply suggests that the widget should be redrawed. Some other timer which is linked with the vertical refresh checks the widget and then calls the paint procedure if need_repaint or some other such flag is set. This way, no matter how many events are called, we will only redraw the widget when it's useful to do so.

The obvious problem with this is synchronization. We could easily run into the problem of the data structures being altered while trying to redraw, which would be a horrible thing. Thinking about the usage of the code, we know that whenever repaint() is called the widget is -- supposedly -- in a drawable state.

We can think of this much the way schedule() is used in the kernel. Whenever schedule() is called, we assume that it's a valid point to pre-empt because all of the code should be prepared for a new process to run at that point.

Rather than having repaint() set a flag and having a separate drawing loop, we modify repaint() to only run when another flag is set called vert_refresh. vert_refresh can be set by something that monitors the vertical refresh on the monitor. If vert_refresh is true, we will repaint the widget immediately when repaint() is called. If not, we won't redraw until the next call to repaint().

This has its own problems. In particular, if we're outside of motion events, there may not be enough calls to repaint() and we'll lose an update unexpectedly.

One potential way to deal with this is to add a separate call called repaint_aligned() which uses this new alignment behavior. This can be used while motion events are still happening, and then a final repaint() can be called when the mouse_released event happens (i.e., there will be no more motion events).

Comments?