It's reproducible on Win2000/ [jdk1.3.1](03) & [jdk1.4](fcs)
but not on Solaris8(CDE) / [jdk1.3.1](03) & [jdk1.4](fcs)

Visible on Windows only. It seems there is performed twice the repaing
method also on linux, will investigate the cause of that.

It's reproducible on Win2000 / [jdk1.4.1](13) too.

does it happen with NB 3.3.x?

Peter, try to search event queue for repaint requests and where they
come from.
Very hard to fix issue IMO.

I already tried it (with the repaint requests). There are planned the repaint tasks for the compoents 
itself sooner, than the main window itself. It leads on Windows to paint component first, than main 
window background, and the rest of components are painted again. This is strange since, the same sequence 
doesn't lead to the same behaviour on unix sys (probably better written Repaint manager). This is the one 
problem, but not on our side.

From our side, the problem is how the GUI is constructed in a very complicated and not deterministic 
way at startup, the components are added on the fly, during the showing of main window 
in various event handlers (MainWindow#doShowWindow is the starting point). There is manipulated with the 
bounds etc.
Anyway I tried to supress it and still got the same behaviour, (there smells something, have no idea 
where), tried to make a testcase with desktop pane, but there was everything fine.

Next will investigate which build was fine as last one.

The problem is also in 3.3.2

Will look further.

Changing target milestone.

Reason: Solving this issue would require redesign the GUI creation part of startup 
sequence, and at the moment isn't known how to achieve the required one. It seems it 
could take more time to find it out.

Do you approve the change of target milestone?

Since this is highly visible bug which could make somewhat 
unprofessional impression (that's why it is P2), I would 
like to put some more effort into trying to fix this, 
before we give up and postpone till 4.0.

To keep all sides informed: already several mandays was invested to
fix the bug, with no luck yet.

My opinion - I vote for concentrating on other bugs for now, simply
because there are too much other serious bugs.
However another fixing attempt in 3.4 timeframe sounds reasonable,
ASAP (means when bug emergency finishes).

I spent more than two days with the issue already, and haven't found a
  straighforward easy soulution, even got no exact way how to solve it
in the case we weill redesign the sequence (bounds setting problem,
etc, also any other hacks in background like synch of maximized state
etc.). 
I guess it will require much more days to find out the proper solution
and fix the issue.

Ofcourse I could overlook something important. Maybe if somebody else
will try to look at the prob, it could help.

Target milestone was changed from '3.4' to TBD.

Target milestone was changed from '3.4' to TBD.

Target milestone was changed from '3.4' to TBD.

Target milestone was changed from '3.4' to TBD.

Set terget milestone to TBD

Set terget milestone to TBD

Is purelly dependant on the #issue 24593. See there.

This bug is reported in version <= 3.4dev and still not fixed. Due to that it
forbids the release candidate for 3.4 to be promoted. Are you aware of that and
are you intensively working on the fix? If not, you should consider some
corrective action.

There was already spent some time on the fix (see above comments).

I think following about that: The possible fix is in no way easy. 
It requires completely redesign the startup of GUI. The current state
is complicated due to a solution of another kind of problems
(e.g. setting bounds).


Then (at least I hope so) it was agreed that target milestone is
postponed to 4.0. Now I set it to future, because there needs to be
figured out, how the startup of GUI should look like, and can't guess
how much of work it could take.
Anyway I'm almost sure it is not fixable in short time.

So what corrective action should be taken now?

The process for "waivers" needs to be announced by release
coordinator. I suggested to just change the mileston to 4.0 or future.
 If accepted your bug is in "waiver" state.

Justification explains the above comments.

I approve of the waiver.

I agree with the waiver

Ian: Please let me know, how important is to fix this issue to 4.0.

Since the new winsys was stopped, fixing this issue would require
quite a lot of changes+time.
I'd need to know whether I should push the problem, to get the needed
time.

If it is a big amount of work, and the winsys will be rewritten
anyway, I'd say it can wait.
Are there going to be some performance-related changes in winsys that
this fix could piggyback on?

Well, I don't know which performance changes will be taken in winsys,
I just know there is planned something.

Anyway, I don't expect performance changes would affect this, since
the problem of this issue is not in performance, but in nature of
startup of win sys.
 Currently it is undeterministic and caused by the implementation of
winsys (especially the way of showing workpaces/modes/topcomponents).

It is necessary to achieve sequence:
1) get all components going to be opened (from
workspace/modes/topcomponents)
2) create hierarchy from them
3) pack
4) show 

The current state is far away from this natural flow. It is also
connected with problems of computing bounds.

I've reread the bug description, doesn't seem to be P2.  Lowered prio
to P3.  It has been waived without much objection two times in a row.
 Should be solved as part of winsys rewrite.

BTW, I noticed JBuilder suffers the same problem on Windows, something
deeper than a flaw in our current winsys?

Well, it could be something deeper. But I think, when we will able to
construct the GUI in typical swing way -> add all components to
hierarchy, pack them and show them, there shouldn't occure any blinks. 
On the other hand, I'm already watching problems with toolbars, which
component is created (can be manipulated -> put into hierarchy), but
its buttons were adding just afterwards (when FolderInstance produces
them), and that design could cause similar problems (keeping it in
mind). And there could occure also pure repainting problems of
individual components.

Because Window System v1 will not be supported from now by our team, all old
winsys issues (now "core/window system v1" issues) are going to be closed as
WONTFIX. 

Changes in API which emerged both from UI spec 
and problems with adjusting to the older API are described in the document
http://core.netbeans.org/windowsystem/changes.html.
 It shows also recommends how the client code should be adjusted to the new
window system.

If you think this issue apply also to the new winsys then change the
subcomponent (to "core/window system") and REOPEN it.

Still reproducible with the new winsys on Windows platforms and Sun
JDK 1.4.2_01. Reopening.

Now it is almost clear it is caused by menubar/toolbar implementation,
using FolderInstance, and even after waitFinished, the GUI is not yet
created and validated..

you can see the effect more closely when you run ide with switch
-J-Dawt.nativeDoubleBuffering=true

Thus making this issue dependant.

it happens on Linux too (visible with native double buffering turned on)

affects startup performance

It doesn't blink on linux, you can just watch what is happening using
that flag.

Possibly related:  jdk bug 439857 - unnecessary painting of Frames 
when first shown.  Looks like it will be fixed in 1.5; for 1.4, we 
might be able to work around it with a custom root pane;  I've 
already patched winsys to make the root panes opaque.

Quoting from the issue:

There are a couple of problems contributing to this.
1. The child of the JFrame (JRootPane) is not opaque.
This is problematic because JComponent.paintImmediately will loop 
until it finds a !opaque JComponent. If it gets to a Component that 
isn't a JComponent it'll invoke repaint on it.  This lead to 
excessive repaints on the Frame. This is fixed by invoke setOpaque
(true) on the JRootPane created for the top levels 
(JFrame/JWindow/JDialog/JApplet).

2. When a top level's size changes the JRootPane gets resized too, 
leading to a pending repaint (from the AWT side) for the top level, 
and a pending Swing repaint for the JRootPane.
This can be fixed by making the RepaintManager know that it is about 
to paint a RootPane and if necessary cancel any pending AWT paint 
events that would generate the same thing.

FYI, I've confirmed it - bug 439857 is the source of the problem.

I'll attach a patch - I did some experimenting with a custom 
RootPane subclass which fires no events on resize.

The good news:  It fixes the flashing.
The bad news: The main window is completely unresponsive (not 
surprising).

I'll attach it as a start - probably the thing to do is simply to 
fire no events on the first call to reshape().

A couple things that don't work:
 - It's not a ComponentListener that triggers it (probably hierarchy 
event or something) - just overriding addComponentListener as a no-
op doesn't work
 - Turning off root pane checking and adding directly to the JFrame 
instead of to its content pane doesn't make any difference - the 
root pane is there whether we use it or not.

Possible alternate solution, but might have its own problems:  Use 
java.awt.Frame instead of JFrame.

Created attachment 12564 [details]
The beginnings of a fix - or at least demonstrates the problem is really where I thought it was

*** Issue 37701 has been marked as a duplicate of this issue. ***

I have what may be a fix for this - I developed it on my mac, so it
needs to be tested on Windows - swing on the mac has hardware double
buffering, which can hide some ugliness.

What it does:
 - In a static block in MainWindow.java, so it runs when the class is
loaded, an alternate RepaintManager is installed
 - This RepaintManager makes almost all repaint operations no-ops (in
reality it should special-case the splash screen)
 - Override MainWindow.validate() to be a no-op until a flag is set
 - In MainWindow.initializeBounds, reset the validate flag and
uninstall the custom repaint manager so painting works normally

It eliminates the flash - the first repaint will come from an AWT
PaintEvent (no way to avoid that, so we just avoid all the other paint
events).  As a bonus, we might get a trivial startup time improvement
- RepaintManager.addDirtyRegion & addInvalidComponent were called
around 9000 times (!!) when I logged them during startup (mostly by
components that are not really onscreen, so they're nearly no-ops anyway).

There will still be a repaint when the toolbars populate themselves -
they are added empty and then populate themselves one-by-one (this
should be fixed at some point - there's no good reason for it to be
done that way).

I noticed two calls to MainWindow.validate() that don't seem to do
anything except generate useless repaints - one in initializeBounds
(if you set the bounds of a window, it will validate itself), and one
in ToolbarPool (this one may do something useful when changing toolbar
configurations, which aren't used by anything anymore).

I'll post the results when I try it on a non-Apple machine.

*** Issue 39668 has been marked as a duplicate of this issue. ***

FWIW, I added a bunch of logging to MainWindow.validate() and found
that the main window was being fully laid out 7 times during startup
due to each toolbar calling validate().  That's fixed;  I also added
an off-by-default workaround for this problem, which is to simply
ignore the first call to doLayout().  If you'd like to test it, run with

-J-Dnetbeans.winsys.flashhack=true

This simply blocks the first validation (which comes from the resizing
ComponentEvent sent when the main window is first shown).  I put the
workaround in mainly to measure the impact on startup time of this
problem - getPreferredSize() is not the cheapest call in the world for
trees and such, so eliminating gratuitous layouts will help startup time.

Note JDK 1.5 beta 2 does not automagically fix the problem - the
behavior is the same in 1.4 or 1.5.  Some numbers would help make a
case for getting it fixed.

I'll do some more research and see if there's a safer way to do this -
I wouldn't want to find that on the one platform where it works
correctly (?), the main window never gets laid out :-/

*** Issue 41576 has been marked as a duplicate of this issue. ***

I think at least partly this issue was fixed by changes in the window
regarding JSplitPane.setDeviderLocation() to
JSplitPane.resetToPrefferedSized(). which simplified the startup
sequence and eliminated some of the repaints. 
Can someone validate if the issue is gone or not?

It's not gone. I can reproduce the extra repaint (blink) easily on my
Windows NT box when starting with no project open. Obviously, when
there is an open project, scanning of project's structure comes to
play which makes the UI temporarily flash and freeze even more, but
it's a different issue.

Tim, perhaps you should take over this issue from Dafe

Tim already did a lot of investigation (I'm delighted),so yes, Tim is
the right person. But I wouldn't expect total fix anytime soon,
toolbars and startup sequence may play role here as well.

The correct java bug number is 4939857, ostensibly fixed in 1.5

If so then we should close this bug, after verification of course

Still reproducible with 4.0 build #200408121800 on JDK 1.5 b63
(latest). The main window area is redrawn (flashes) once during the
startup sequence.

FIrst, do we know that there is one *less* repaint on 1.5 than 1.4, during startup - that is, 
was the JDK issue really fixed?

After that, there is the matter of toolbars - the way it is done now, the toolbars are 
created, but then populated lazily - this code does need to be rewritten, but is unlikely to 
for 4.0.

Finally, there are assorted calls to MainWindow.validate() that may be able to be 
eliminated.  But there are a lot of variables here, toolbars being by far the worst of the 
bunch.

Toolbars are now created synchronously BEFORE they are displayed. This
was fixed recently. See issue #46016.

Spent some more time poking at this, but still no obvious culprits.

Note that the hack does work - if you run with
-J-Dnetbeans.winsys.flashhack=true

you won't see the flash.  This issue is  a little more severe now, 
since if the timing is just right, the classpath scanning stuff will 
hijack the AWT thread just after the main window has gone gray, so 
you can occasionally see the main window go gray for 10s or so on 
startup.

Possibly if the hack could be enabled only for <= JDK 1.5 on windows, 
it would be safe enough.

Re-assigning Tim's issues to Dafe.

Passing to Stan to distribute bugs evenly. Thanks Stane :-)

*** Issue 50937 has been marked as a duplicate of this issue. ***

fixed

i integrated the patch kindly provided by ericarseneau (see issue
50937 ) and removed the repaint call from the setDesktop method and it
seems to be working fine in jdk 1.5. 
however i had to add a hack to repaint the main window when it's being
maximized for the first time (setExtendedState()).

pls reopen the issue if you think this fix is not good enough.

Checking in windows/src/org/netbeans/core/windows/view/ui/MainWindow.java;
/cvs/core/windows/src/org/netbeans/core/windows/view/ui/MainWindow.java,v
 <--  MainWindow.java
new revision: 1.40; previous revision: 1.39
done

verified in NB4.1(200503281924)