Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] viewer.getControl().setRedraw(false);

I guess the TreeViewer could be made to be a bit smarter by recording average times for individual operations. 
This way the threshold would be determined dynamically, using the unique combination of hardware+OS.
 
 
Friday, April 15, 2005 12:25 PM
To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc:
From: John Arthorne/Ottawa/IBM@IBMCA
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


Back to the top