Re: [platform-ui-dev] viewer.getControl().setRedraw(false);

[Nick Edgar <Nick_Edgar@xxxxxxxxxx>]

The viewers used to do more setRedraw(false/true) themselves, e.g. around 
a full refresh, and this did cause widespread flashiness.
They were taken out of JFace (in 1.0 or 2.0), but some clients still did 
this to avoid the creeping scrollbar problem.

As McQ says, the lower levels like SWT and JFace don't have enough info to 
make a good decision here, since the higher level may be issuing many 
fine-grained updates.

Can the SWT team comment on the current best practice for this problem? 

Nick




John Arthorne/Ottawa/IBM@IBMCA 
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
04/15/2005 12:25 PM
Please respond to
"Eclipse Platform UI component developers list."


To
"Eclipse Platform UI component developers list." 
<platform-ui-dev@xxxxxxxxxxx>
cc

Subject
Re: [platform-ui-dev] viewer.getControl().setRedraw(false);







This is a good question.  setRedraw false/true is often a tempting fix 
when performance is bad.  The thing to keep in mind is that calling 
setRedraw(true) will redraw the entire tree, resulting in a "flash".  Do 
this too often, and you have a disco ball UI that is always flashing. The 
repositories view was doing this in M6 (see bug 90096).  This looked bad, 
since even the slightest update would cause the entire tree to be redrawn. 
 It was particularly flashy on GTK, but also flashed on Windows.  However, 
setRedraw false/true does make the very big tree cases faster.  I have 
found the repositories view and the debugger to be terrible on very large 
trees since the setRedraw was removed (see later comments in bug 89865). 
It's difficult to choose between fast and flashy vs. slow and smooth.  If 
TreeViewer could distinguish very large updates from small ones, and only 
turn off redrawing for the large ones, it would be the best of both 
worlds.  However, I suspect that figuring out an appropriate threshold is 
highly dependent on the OS and windowing system being used. 



"Ed Burnette" <Ed.Burnette@xxxxxxx> 
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx 
15/04/2005 11:24 AM 

Please respond to
"Eclipse Platform UI component developers list."


To
<platform-ui-dev@xxxxxxxxxxx> 
cc

Subject
[platform-ui-dev] viewer.getControl().setRedraw(false);








This is a design question concerning where to put setRedraw() calls in the 
Platform.

Background: In the CVS Repository view, RemoteViewPart.refreshViewer() 
calls TreeViewer.refresh(). If you have a couple thousand items in the 
tree and you're running on Windows this takes a few seconds. First you see 
the scroll bar thumb get bigger and bigger as items are sucked out of the 
tree, then there's a flash, then items start populating back in and the 
scroll bar gets smaller and smaller. The Eclipse UI is unresponsive during 
this period. If you plug the speakers in you'll hear a "woooOP! Whoooo" 
sound as this happens (j/k). 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=91558 has been filed to 
track this particular problem.

A setRedraw() call at the right place can fix this, though it makes it 
much less interesting to watch. I'm not sure the best place to put it 
though.

Fix 1: in RemoteViewPart.refreshViewer(), surround the refresh call with 
setRedraw(false) and setRedraw(true) calls, like this:

                                 viewer.getControl().setRedraw(false);
                                 viewer.refresh();
                                 viewer.getControl().setRedraw(true);

This would affect only this one spot in the CVS view.

Fix 2: Put the calls inside TreeViewer.refresh() (Actually 
StructuredViewer.refresh(Object)). This would affect all structured 
viewers.

Fix 3: Put the calls inside AbstractTreeViewer.internalRefresh(Object).
Fix 4: Put the calls inside AbstractTreeViewer.internalRefresh(Widget, 
Object, boolean, boolean) (called from the routine in Fix 3).
Fix 5. Put the calls inside 
AbstractTreeViewer.internalRefreshStruct(Widget, Object, boolean) (called 
from the routine in Fix 4).
etc... all the way down to SWT. See 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=91558 for the full 
tracebacks.

So basically the question is should setRedraw() calls be done at as high a 
level as possible, as low as possible, or somewhere in between? Should it 
be done in one place that affects everybody or in lots of places as cases 
are found (CVS Repository, Package viewer, Outline view, etc.)? And should 
it be conditional on the size of the operation, if that can be quickly 
determined?


_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev