This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 34573 - Avoid slow repaint immediately after closing a wizard
Summary: Avoid slow repaint immediately after closing a wizard
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Dialogs&Wizards (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords: PERFORMANCE, UI
Depends on:
Blocks:
 
Reported: 2003-06-24 21:32 UTC by Jesse Glick
Modified: 2008-12-22 13:42 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-06-24 21:32:04 UTC
If you have some dialog (normally a wizard) which
performs some fairly serious work when you click
Finish - File -> New for example - you often see
an unpainted grey rectangle for a moment where the
wizard was, right after you close it, especially
on slower machines.

As I understand it, this is due to the fact that
Swing gets a repaint request once the wizard is
closed (and the underlying NB window is exposed),
but the event thread is competing for CPU time
with whatever thread is doing the wizard's work
for a second or so. The event thread might not
even be scheduled until noticeably later, during
which time you see this ugly rectangle.

This is true generally of any situation where
repaints are competing with other work, but it is
especially noticeable in the case of closed
wizards and so contributes to a perception of
sluggishness.

It would be nice to eliminate this problem, so
that the exposed window is painted promptly, even
if that makes NB take a fraction of a second
longer to actually complete the wizard's work.

My first suggestion was to introduce a small delay
into firing of WizardDescriptor.PROP_VALUE ->
FINISH_OPTION. Perhaps 100msec - enough to do a
repaint, or at least *begin* a repaint (so that
the event thread is scheduled and working and less
likely to be preempted). That might work for
nonmodal wizards which display the dialog and then
wait for the property change.

Unfortunately that will not work for most modal
wizards (e.g. File -> New), which are generally
coded to create a dialog, then call show()
(blocking until it is closed, using a nested event
queue), then process the result if desc.value ==
FINISH_OPTION.

In this case the only fix I can imagine is in the
particular code which displays the modal wizard;
it could call show(), then do the rest of its work
in a separate thread (or AWT, using invokeLater)
but only after a pause. I can't think of a general
way to do it from the dialog-displaying code (e.g.
NbPresenter).

If you have any ideas, please consider this
responsiveness tweak, otherwise WONTFIX.
Comment 1 _ rkubacki 2007-01-04 21:06:48 UTC
Probably WONTFIX thanks to grey-rectangle fix in Java 6. At least I do not
experience this problem now.