Move Splash initialization to EDT and make it no longer modal

[mbien]

• about 100ms faster startup since some of the swing initialization moved off the main thread (Main#start method execution time measured) and technically more correct anyway
• use JFrame to get double buffering (no progress bar flicker during repaint)
• other change: splash window is no longer modal
• code modernization

have to test the dev build on other systems, esp how it interacts with the Java 6 --splash JVM feature (doesn't seem to be used from the linux launcher). I suppose that one would be still modal before its replaced but its hopefully not noticeable.

more startup optimizations to come later

closes #8557

[neilcsmith-net]

+1 to moving the Swing initialization into the right place.

From what I recall, the JVM --splash feature is never used any more and has been disabled since #1246

Since that PR we really should have some code in Splash to set the WM_CLASS on it. The code at https://github.com/apache/netbeans/blob/master/platform/core.windows/src/org/netbeans/core/windows/view/ui/MainWindow.java#L127 comes too late. We have a workaround in the NetBeans installer builds to work around this with the desktop file name, but it's not ideal. I did look at this once, but getting the right value is difficult - maybe just need a different branding token for it. Not saying you have to look at that in the context of this PR either! Just making a note.

I assume by "no longer modal" you mean the window type? What changes does that introduce across OS? Curious why it was felt necessary originally?

[mbien]

if the modal change is controversial I can revert it. This is the first of a series of startup optimization PRs - I started with the simple changes. The modality issue was just a drive by change since I had to test it anyway but not the goal.

edit: one aspect where this is useful though is while debugging. If you have a breakpoint somewhere in the initialization phase the modal splash is often in the way when wanting to see the debugger.

[neilcsmith-net]

No issue with the modal revert in my opinion, even if it does bring that old issue back in fixing another one.

I'd still like @eirikbakke opinion as he made the changes in #1246 I'm also curious looking at the docs for SplashScreen to revisit why using that support was not enough for hi-dpi.

Once that's resolved I'll see if I can fix that WM_CLASS issue in here too, as the workaround in the installers is a little fragile.

[eirikbakke]

Thanks for this!

Reading over the Splash class, it does not seem to be very thread-safe, nor does it document which thread may access each method. My impression is that the Splash class is externally accessed from the "main" thread, i.e. thread on which main(String args[]) was originally called. Is that right?

For example, SplashComponent (comp) is constructed on the main thread, though it really should be constructed on the EDT. After this PR, it is added to the Frame (frame) on the EDT. In another example, SplashPainter.barLength is updated on the main thread and read on the EDT, without synchronization or "volatile" anywhere.

Perhaps we'd need to clean up the rest of the threading issues in this class, before we can safely move any of the code between threads? It's possible that some of this worked only by accident before.

On the modality thing: Sure, sounds good to make it non-modal. I tested it on MacOS and didn't see any problems with it.

On the USE_LAUNCHER_SPLASH = false thing: I could not get this working with HiDPI on Windows in the past. It's also quite a lot of complexity spent on getting the splash screen to show just a tiny bit earlier in the startup cycle. I don't think it's worth trying to reintroduce it. (On the contrary, it might be a good cleanup to just get rid of the related code, e.g. the part that stores the png of the splash screen to make it available for the splash parameter on next startup etc.)

On WM_CLASS: It's good to have this set properly, yes! Is your concern that it is not being set on the splash screen frame, only on the eventual main window?

[mbien]

For example, SplashComponent (comp) is constructed on the main thread, though it really should be constructed on the EDT

overlooked that one. will try to move that somewhere else too after I entangled the spaghetti code

I just realized that showAboutDialog() isn't used anywhere so the inner class I renamed is dead code.

[mbien]

this is a mess. The test only worked because it completed before the EDT ran.
max steps are hardcoded in the init method. Test expects that the set values are used.

netbeans/platform/core.startup/src/org/netbeans/core/startup/Splash.java

Lines 448 to 450 in 26a05a6

	// 100 is allocated for module system that will adjust this when number
	// of existing modules is known
	maxSteps = 140;

[mbien]

Tried to make this work without rewriting everything. Also switched to JFrame too so that the progress bar doesn't flicker on update.

[neilcsmith-net]

On the USE_LAUNCHER_SPLASH = false thing: I could not get this working with HiDPI on Windows in the past. It's also quite a lot of complexity spent on getting the splash screen to show just a tiny bit earlier in the startup cycle.

Well, it also has the benefit of not having WM_CLASS set on it. But I remember the discussion around the issues. I know you can change the image via the API after it's shown, but that's probably not a useful workaround ..

On WM_CLASS: It's good to have this set properly, yes! Is your concern that it is not being set on the splash screen frame, only on the eventual main window?

The problem is not that it isn't set, but that it's set to the default. If you start up the toolkit in the main thread, you'll get the name of the main class, but off another thread like we are, the splash gets WM_CLASS set to java-lang-Thread. See https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L393

This started being a problem when we stopped using the JDK splash. And why we get duplicate icons in Linux docks if relying solely on matching against WM_CLASS. Of course, we could match Java-lang-Thread but then other Java apps start getting the NetBeans icon. At least GNOME also does some text matching on the name of the desktop file. This is why NBPackage has the ability to customise the desktop file name as well as the desktop StartupWMClass match. It's unknown which Linux desktops this actually works correctly on! See also https://github.com/codelerity/netbeans-packages/blob/main/config/linux-x64-deb.properties#L20

[eirikbakke]

This started being a problem when we stopped using the JDK splash. And why we get duplicate icons in Linux docks if relying solely on matching against WM_CLASS.

Oh, interesting. So the JVM splash becomes a possible workaround. There seems to be two options:

1. Re-enable USE_LAUNCHER_SPLASH on Linux, ideally making it work with HiDPI screens first. The latter would likely require storing a "splash@2x.png" file in the cache directory along with splash.png. (See GetScaledImageName in OpenJDK for the naming convention per JDK-8151787.)

2. Set WM_SCALE in Splash.java, with the challenge Neil mentioned of finding out what the right value should be.

Might be good for a separate PR after this one is merged, since I suspect the threading and cleanup stuff will make this one complex enough already.

(EDIT Also, is it so that not having WM_CLASS set on the splash screen also solved the duplicate-taskbar-icon problem on Linux? Then a third option would be to un-set WM_SCALE in Splash.java....)

[neilcsmith-net]

Yes, let's get @mbien changes in first, and then consider this problem. Let's keep USE_LAUNCHER_SPLASH as is - different behaviour for different OS is always a pain. We can't unset WM_CLASS, but I would be tempted to move it out of MainWindow and set it as part of the early startup, using a value from the core.startup bundle instead. Can possibly add at https://github.com/apache/netbeans/blob/master/platform/core.startup/src/org/netbeans/core/startup/Main.java#L247 or in Splash::setRunning before the --nosplash check. Former would ensure it's set before the import dialog if need be. Either way, needs to happen after the toolkit is initialized.

[mbien]

yep lets try to get the discussion back to this PR. This is primarily about EDT offloading (which is also technically a concurrency bug fix). Secondary is the modality change which can be reverted if there are concerns. Everything else would be followups - which would be appreciated since the code would benefit from more refactoring/cleanups (or a green field rewrite of the splash functionality).

[eirikbakke]

I looked through the latest version. Splash.java still has various threading issues. For example:

• SplashPainter.increment and SplashPainter.addToMaxSteps touches a bunch of fields from the main thread that are also accessed from the EDT in paint().
• Splash.print, Splash.increment, and Splash.addToMaxSteps all access the non-volatile field "painter" from the main thread, but painter is assigned on the EDT.
• SplashPainter.setText accesses the non-volatile field "text" from the main thread, but that field is accessed from the EDT in adjustText.
• Splash.getComponent() is called from a thread other than the EDT and used as the parent of a dialog that is created off-thread.

Threading issues have also clearly been an issue in the past, see e.g. the comment "run in AWT, there were problems with accessing font metrics". So if we touch threading at all we might need to do it properly...

Some things that might help:

• Making sure that all immutable fields have a "final" keyword, in particular in SplashPainter. (final fields will need to be initialized from a real constructor).
• Adding a comment before each method and mutable field, indicating which thread is allowed to access them (main or EDT or both). Fields that can be accessed from multiple threads must be accessed through a synchronized block or other tread-safe mechanism (e.g. volatile reference to an immutable value).

[mbien]

Threading issues have also clearly been an issue in the past, see e.g. the comment "run in AWT, there were problems with accessing font metrics". So if we touch threading at all we might need to do it properly...

this is a different category of threading problems. One tried to initialize awt and swing code on the main thread which is highly problematic. The other might miss out on an update of an integer increment, which is harmless. Worst case is that the progress is wrong by a few pixels.

I can give this another pass but won't rewrite the whole thing. Esp not while the requirements are unclear given the launchers and the --splash option.

[eirikbakke]

I suppose, the alternative to fixing everything "properly" is to just test it for a while. I'd be fine with that, too.

[mbien]

this is now no longer a small change since I extracted the model from the UI code.