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]

I assume by "no longer modal" you mean the window type?

yes its the window type. It used to be set to POPUP.

What changes does that introduce across OS?

• X11: if you use window effects, they would be more likely to apply to the splash now. (e.g window popup animation or shadow). But most defaults are fairly conservative here, e.g it usually fades in and has a slight shadow.
• wayland: well. window positioning is not implemented still, applications tend to give up on splash screens and simply not render them since they would pop up on a random spot on the screen
• on tiling WMs: i have no clue, might look funny. Simply start with --nosplash if there is a problem i guess.
• win 11: it appears to work fine
• mac: I don't know

Curious why it was felt necessary originally?

not sure. But back in the days it was more common to see modal splash screens. While the system was busy opening something, you wouldn't be able to use it anyway. Today, systems are usually under utilized even on application starts due to vastly improved hardware capabilities (NVMe, multicore etc). Perceived performance was improved by making splashes pop up as fast as possible so that it looked fast - today this is not really a concern I think.

[neilcsmith-net]

I think you've slightly misunderstood why I asked. Taken a look back in the archive repo and bugzilla for that issue. Looks like the window type was added in 7.2 to fix issues with tiling WMs, so the workaround there goes back to what it was before. Unless I'm missing something, I don't see anything that made this modal before that change.

[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).