On Fri, Mar 25, 2011 at 9:32 PM, Jeff Larsen <[email protected]> wrote:
> Currently, Cell-backed Widgets redraw themselves every time a change is made. > This leads to degenerate performance where you create the widget, then > call 4 setters, and the widget is rendered 5 times! I'm going to propose a > solution where we defer rendering and add a flush() command toCellWidget, > but that will require a design doc and a separate CL. > > > Couldn't you check to see if the widget is attached, and if it is, reddraw, > if it isn't, don't do anything and then render in onAttach(), or you could > also add a DeferredCommand to the cell widgets and everytime you set > something that would normally cause a redraw, the defferedcommand is > scheduled. Then multiple setters could be called and once a free cpu cycle > is given, it will redraw all the changes at once. > I didn't clarify, but I meant that we would use a deferred command (or really, a finally command so it happens at the very end of the current event loop). I think we should still provide a flush() method so the user can force a synchronous redraw, but calling flush() would be optional and most users will only need to use it occasionally. > > Then we wouldn't need a flush method. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
