Re: [e4-dev] Proposal to replace the 'visible' flag

[David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Oct 21, 2010 at 12:52 PM, Eric Moffatt <emoffatt@xxxxxxxxxx> wrote:

- Handles multiple attribute changes to the same element (i.e. label, tooltip and icon) to be handled in a single sych, right now we set each separately causing 3 updates in the UI).
- Allows at least the potential to optimize sets of changes by examining the complete list of pending changes

The big advantage though is that it makes the rendering simpler by removing the necessity for each discreet renderer to create its own set of discreet listeners, all they would have to do is to write the 'synchUI' merhod. Of course care should be taken in 'synchUI' to minimize the impact on the rendered widget (i.e. Only call 'setText' on the widget if it's different from what's already there...).

From your experience do you have any hints as to whether this is better/worse than the current state ?

IMO, the current state is better for the simple/naive case.  It's a simpler programming model.

But I've had to abandon it most times I am composing multiple discrete UI controls together to get an overall effect because often I wind up with:

a) Too many UI updates.

b) Being unable to predict the order in which events will arrive on various platforms leading to subtle, hard to find/fix cross-platform redraw bugs.

c) Just generally being in a position where the code trying to do the UI update doesn't have a global enough perspective to do what it needs to do, so it has to set some flag/value, then asyncExec to something else that actually does the update anyway.

In that case, having the code explicitly represent the following pipeline seems to work much better:

• Handle some event
  
• decide we have to redraw; maybe mark the relevant part dirty; if we haven't already posted a redraw event to the SWT async queue, do so.
  
• capture whatever state the event contributes to the eventual redraw operation
• In the async redraw event:
  
• Recalculate the entire redraw operation once
• minimize the number of UI updates
• sometimes: optimize their order (this can be the difference between keeping up with keyboard auto-repeat and not)
  
• sometimes: build a data structure representing the pending UI update (in cases where the UI update itself is very expensive)
  
• Actually update the UI
  

Hope this makes better sense. :-)

I'm not positive how this applies to the E4 programming model, but I expect you might.  If you'd like, feel free to call me this afternoon (630-344-3979) and we can talk about it.


Regards,

Dave