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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

Try turning off the windows tree animation.
 When turned off, I don't think inserting a TreeItem takes very long.
To turn off tree animation, turn off the menu animation property found
in Display Properties, Appearance, Effects.  Of course this solution
requires the user to do something.

-Randy

Nick Edgar <Nick_Edgar@xxxxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

04/15/2005 01:49 PM

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

To	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc	platform-swt-dev@xxxxxxxxxxx
Subject	Re: [platform-ui-dev] viewer.getControl().setRedraw(false);

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


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