Community
Participate
Working Groups
Is there any way to get the splash screen to be able to be in jpeg or png format in addition to BMP? In cases where splash screens are translated, having one per language can get pretty expensive in terms of file sizes if the only option is BMP formatting.
Moving to SWT since they own the launcher executable.
I thought that the .BMP restriction was removed a while ago. Silenio?
No, it still has to be a BMP.
Will this be sorted out sometime soon? I'd quite like to have a splash with alpha channel transparency...
Since 3.3 you can use SWT to modify the splash screen, so you could add transparency then, but the normal bmp will be shown until you get to your java code. To get formats other than bmp, we need native implementations for all supported windowing systems: win32/wpf : We would need to use GDI+ or the Windows Imaging Component, I don't know the details and what kind of dependencies this pulls in. gtk : works now, you just need to point -showsplash at a png file using a full path since the launcher looks for "splash.bmp" by default carbon: On > 10.4, we use CGImageSourceCreateWithURL, I'm not sure, but this may support png, try an absolute path like for gtk. On 10.3 this will not work, we use the same code as motif motif: I have no idea We don't currently have the resources to do this in 3.5
I did try a SplashHandler but couldn't get the transparency to work - the alpha on the PNG I used just showed up black. Any tips appreciated - couldn't find an answer in the newsgroups/google as to what I might be doing wrong. Also, perhaps a little off topic, but when I didn't specify a splash bmp in the product (this was on XP) the splash handler was not invoked. Is this expected? Having an image with non-transparent areas for a few seconds suddenly become transparent would be a bit weird, no?! Err just realised I should take my Q's over to the newsgroups... 8) but the answers would probably be useful to others who find this old bug!
If think the Linux launch already can do this, Alex please correct me if I'm wrong. No idea about Windows or Mac. Does anyone know?
Honestly, I am not sure. I would refer to Sravan as a source of truth here.
(In reply to Lars Vogel from comment #7) > If think the Linux launch already can do this, Alex please correct me if I'm > wrong. > > No idea about Windows or Mac. Does anyone know? I took a look at native launcher code (well hidden in rt.equinox.framework\features\org.eclipse.equinox.executable.feature\library). Both GTK and Cocoa launchers can use any format supported by the platform (including PNG and JPG). Win32 launcher needs a rewrite of image loading code to be able to use JPG/PNG. Neither the launcher nor SWT support semi-transparent windows, so loading PNG with an alpha channel is pointless.
(In reply to Nikita Nemkin from comment #9) > I took a look at native launcher code (well hidden in > rt.equinox.framework\features\org.eclipse.equinox.executable. > feature\library). Thanks Nikita > Both GTK and Cocoa launchers can use any format supported by the platform > (including PNG and JPG). Win32 launcher needs a rewrite of image loading > code to be able to use JPG/PNG. Could you help here Nikita?
(In reply to Lars Vogel from comment #10) > (In reply to Nikita Nemkin from comment #9) > > Thanks Nikita > > > Both GTK and Cocoa launchers can use any format supported by the platform > > (including PNG and JPG). Win32 launcher needs a rewrite of image loading > > code to be able to use JPG/PNG. > > Could you help here Nikita? Yes, the change is pretty simple.
We are past M3, this will need to wait to next release.
(In reply to Nikita Nemkin from comment #11) > > Could you help here Nikita? > > Yes, the change is pretty simple. Ping
(In reply to Lars Vogel - Out of Office until 05 August 2019 from comment #13) > (In reply to Nikita Nemkin from comment #11) > > > > Could you help here Nikita? > > > > Yes, the change is pretty simple. > Any chance for M3?
Moving out to 4.14 unless
(In reply to Thomas Watson from comment #15) > Moving out to 4.14 unless Hit submit before completing this ... Moving out to 4.14 unless others have plans to get this done this week for M3.
Dropping milestone until someone agrees commit to work on this.
Nikita, do you still plan to work on this?
(In reply to Lars Vogel from comment #18) > Nikita, do you still plan to work on this? Sorry, not at the moment. Writing the code isn't the problem, but I hit the wall trying to build it, let alone test it. Upgrading Launcher build process from Win 2003 SDK to Win 10 SDK would help, but I'm clueless w.r.t. Eclipse build infrastructure.
Thomas, can you comment on the build process and if we can update it?
@Niraj, Can you please help Nikita with windows build setup? Launcher uses same build setup as SWT.
(In reply to Sravan Kumar Lakkimsetti from comment #21) > @Niraj, > > Can you please help Nikita with windows build setup? Launcher uses same > build setup as SWT. Nirja, any update?
(In reply to Nikita Nemkin from comment #19) > (In reply to Lars Vogel from comment #18) > > Nikita, do you still plan to work on this? > > Sorry, not at the moment. Writing the code isn't the problem, but I hit the > wall trying to build it, let alone test it. > > Upgrading Launcher build process from Win 2003 SDK to Win 10 SDK would help, > but I'm clueless w.r.t. Eclipse build infrastructure. Hi Nikita, On how to upgrade the Launcher build process, please take clues from bug 526802 which was used to track the SWT build upgrade from Win 2003 SDK to Win 10 SDK.
(In reply to Niraj Modi from comment #23) > (In reply to Nikita Nemkin from comment #19) > > (In reply to Lars Vogel from comment #18) > > > Nikita, do you still plan to work on this? > > > > Sorry, not at the moment. Writing the code isn't the problem, but I hit the > > wall trying to build it, let alone test it. > > > > Upgrading Launcher build process from Win 2003 SDK to Win 10 SDK would help, > > but I'm clueless w.r.t. Eclipse build infrastructure. > > Hi Nikita, > On how to upgrade the Launcher build process, please take clues from bug > 526802 which was used to track the SWT build upgrade from Win 2003 SDK to > Win 10 SDK. I created Bug 559865 for this update
I found it extremely surprising that on Windows the splash bitmap must be "Windows 3.x" format and "Windows 95/NT" format does not work.
(In reply to Mat Booth from comment #25) > I found it extremely surprising that on Windows the splash bitmap must be > "Windows 3.x" format and "Windows 95/NT" format does not work. This bug depends on the update of the build system. See Bug 559865.
Created attachment 284168 [details] Movie 1. Really quick splash
Created attachment 284169 [details] Movie 2. Embedded in the equinox launcher
Changing the splash was alway on my to-do list. I often wondered if it was possible to use the "native" java splash function [1]. I was awake early this morning and after my 10k swim (not) I played with this a little bit. So far it looks quite easy. First I just added a random splash screen to Eclipse. I have attached this as movie1.mp4. Please note the speed of the splash screen. It is displayed immediately. Once the vm is started, you can use the SplashScreen class to get the address of the image and manipulate it. To do this I hacked it into the Main launcher class, just before equinox is loading the eclipse splash. See movie2.mp4 for integration into the launcher. I loop inside the equinox launcher for a while for demonstration purposes. That is why it is delaying. It supports gif, animated gif, png and jpeg format. Unfortunately/Luckily no bmp. Shall I go forward with this? [1] https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html
(In reply to Wim Jongman from comment #29) > Changing the splash was alway on my to-do list. I often wondered if it was > possible to use the "native" java splash function [1]. I was awake early > this morning and after my 10k swim (not) I played with this a little bit. > > So far it looks quite easy. First I just added a random splash screen to > Eclipse. I have attached this as movie1.mp4. Please note the speed of the > splash screen. It is displayed immediately. > > Once the vm is started, you can use the SplashScreen class to get the > address of the image and manipulate it. To do this I hacked it into the Main > launcher class, just before equinox is loading the eclipse splash. > > See movie2.mp4 for integration into the launcher. I loop inside the equinox > launcher for a while for demonstration purposes. That is why it is delaying. > > It supports gif, animated gif, png and jpeg format. Unfortunately/Luckily no > bmp. > > Shall I go forward with this? > > [1] https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html That's cool. Does this then also support high-resolution images?
> > That's cool. Does this then also support high-resolution images? It does. I found it in the java11 doc of SplasScreen: * </PRE> * HiDPI scaled image is also supported. * Unscaled image name i.e. filename.gif should be passed in * {@code manifest.mf}/{@code -splash:} option for all image types irrespective of * HiDPI and Non-HiDPI. * Following is the naming convention for scaled images. * Screen scale 1.25: filename@125pct.gif * Screen scale 1.50: filename@150pct.gif * Screen scale 2: filename@200pct.gif and filename@2x.gif both are supported * Screen scale 2.50: filename@250pct.gif * Screen scale 3: filename@300pct.gif and filename@3x.gif both are supported * The command line interface has higher precedence over the manifest * setting. * <p>
(In reply to Wim Jongman from comment #31) > It does. I found it in the java11 doc of SplasScreen: > > * </PRE> > * Screen scale 2: filename@200pct.gif and filename@2x.gif both are the @2x is the same we use in SWT.
(In reply to Matthias Becker from comment #32) > (In reply to Wim Jongman from comment #31) > > It does. I found it in the java11 doc of SplasScreen: > > > > * </PRE> > > * Screen scale 2: filename@200pct.gif and filename@2x.gif both are > > the @2x is the same we use in SWT. I will push a preliminary Gerrit so that you can play with it as well.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/169562
(In reply to Eclipse Genie from comment #34) > New Gerrit change created: > https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/169562 There are special launching instructions because the Eclipse Run Configuration launches the -splash after the main class. This must be spec'd before the main class. See Gerrit comments.
Looks great Wim, does this also allow to delete the native splash code from Equinox?
(In reply to Lars Vogel from comment #36) > Looks great Wim, does this also allow to delete the native splash code from > Equinox? I forgot to mention that. It probably does. However, I have to study the custom splash handler a bit.
(In reply to Wim Jongman from comment #37) > (In reply to Lars Vogel from comment #36) > > Looks great Wim, does this also allow to delete the native splash code from > > Equinox? > > I forgot to mention that. It probably does. However, I have to study the > custom splash handler a bit. That would be awesome, if I remember discussion correctly, this code is hard to maintain and update.
Created attachment 284192 [details] Transparant PNG Splash I have made some progress with this bug. The JNI bridge that goes into native code to show the splash is removed. Attached two example movies on the cool new splash capabilities. There is a move that uses a 16kb transparent png image, and a movie that uses a whopping 1.2MB animated GIF. Java splash works by specifying an image on the startup. This is a bit of a problem for us because our old splash screen is fetched dynamically based on the product/application that is started (at the penalty of ~1 second delay in splash appearance). We also support language variants so that every language has its own splash. I solved this by providing a one-pixel transparent png as the initial image. This activates the java SplashScreen logic. During the launch logic, the search for the splash is done as usual and the Java splash can be replaced dynamically. This means that we can keep our current splash screen logic. Unfortunately, Java does not support BMP. This is a bummer because the existing clients will no longer have a splash. I could work around this by loading the native library when only a BMP was found but this is an ugly hack. We must decide if this is what we want, or find another solution for the BMP issue, for example, to convert the BMP to PNG during build time. The client can now decide to supply a GIF, PNG, or JPG. The plugin that contains the splash screen is now examined for all variants, in this order. ### Try me You need to run the latest sdk with the org.eclipse.equinox.launcher plugin as a workspace project. Then get the associated Gerrit change. Inside the main package of the equinox launcher plugin you will find the needed files: * startscript.txt This file contains the startup sequence from the command line. You need to look at this and replace the directories with your own directories. If you want to debug you need to make a remote debug run configuration that listens for that port. * empty.png This is the initial SplashScreen image that we replace during runtime. * splash.gif and splash.png Place these files in the org.eclipse.platform in your SDK plugins directory next to the splash.bmp. If both the GIF and the PNG exist, then the GIF will be loaded. ## TO DO The text and the progress bar that are painted on top of our existing splash are not yet implemented. I will look at that if we are still "go". We need to test on different platforms. We need to test if Java likes the URI of the splash image to be in a jar.
Created attachment 284193 [details] Animated splash screen
(In reply to Wim Jongman from comment #40) > Created attachment 284193 [details] > Animated splash screen I guess this will not make it into the official 4.18 release?
(In reply to Lars Vogel from comment #41) > (In reply to Wim Jongman from comment #40) > > Created attachment 284193 [details] > > Animated splash screen > > I guess this will not make it into the official 4.18 release? No, this will be 4.19. I'm still going to fix it, but I have to juggle my contributions outside of my normal job.
(In reply to Wim Jongman from comment #42) > (In reply to Lars Vogel from comment #41) > > (In reply to Wim Jongman from comment #40) > > > Created attachment 284193 [details] > > > Animated splash screen > > > > I guess this will not make it into the official 4.18 release? > > No, this will be 4.19. I'm still going to fix it, but I have to juggle my > contributions outside of my normal job. Any progress here?
(In reply to Matthias Becker from comment #43) > Any progress here? I really think we should go through with this, but it is not a one man job. I need someone who wants to dive in there with me. The current status: ### 1. We can use Java's native splash handling The good part of this is that we do not need any native code to handle the splashing. The native code can be ditched, which makes maintenance easier and the startup a bit faster (no more loading of this code). I have a working scenario for this in the Gerrit. ### 2. It cannot handle BMP Isn't it ironic? The only format we support is not supported by Java and we have to find a solution for it. A workaround would be to convert any BMP splash to PNG during product export. ### 3. Change in product workflow The product configuration (.product file) workflow must be changed. People can now add other image formats. BMP is no longer supported. This requires change in PDE. ### 4. Startup progress The current process is now able to overlay a progress bar and text onto the image. Is this something we still want to support? There is support for it in the Java splash handling. The current code that handles the progress is confusing and needs to be rewritten with an IProgressMonitor like strategy. ### 5. Change in boot code The splash boot code requires that a splash screen is the first argument after the java statement. This is different from the current boot code where this argument is not present. This needs to be figured out (equinox) together with the ditch of the native code.
(In reply to Wim Jongman from comment #44) > ### 2. It cannot handle BMP > Isn't it ironic? The only format we support is not supported by Java and we > have to find a solution for it. A workaround would be to convert any BMP > splash to PNG during product export. Isn't this an incompatible change. This would mean that existing product all need to be touched so that they work with new versions of the Eclipse launcher. Maybe we need to do this in a compatible way (and e.g. keep the old code for the case we still have a BMP splash image).
(In reply to Matthias Becker from comment #45) > Maybe we need to do this in a compatible way (and e.g. keep the old code for > the case we still have a BMP splash image). We should try to avoid that. When people have a splash, they have a product. When they have a product they need to rebuild it with the new launcher anyway. Either we solve it in the build or at runtime (e.g. we do a one-time conversion of bmp to png at startup)
Removing the target now.
(In reply to Wim Jongman from comment #44) > (In reply to Matthias Becker from comment #43) > > > Any progress here? > > I really think we should go through with this, but it is not a one man job. > I need someone who wants to dive in there with me. > > The current status: > > ### 1. We can use Java's native splash handling > The good part of this is that we do not need any native code to handle the > splashing. The native code can be ditched, which makes maintenance easier > and the startup a bit faster (no more loading of this code). I have a > working scenario for this in the Gerrit. Could we make this optional? So if a certain parameter is set, we use the new logic otherwise the old? This would also allow to migrate this smoothly. > ### 2. It cannot handle BMP > Isn't it ironic? The only format we support is not supported by Java and we > have to find a solution for it. A workaround would be to convert any BMP > splash to PNG during product export. Haha. I think if go for the switch option that should be dine. > ### 3. Change in product workflow > The product configuration (.product file) workflow must be changed. People > can now add other image formats. BMP is no longer supported. This requires > change in PDE. That will be easy once we have support for it at runtime. I could do this, once the rest is ready. > ### 4. Startup progress > The current process is now able to overlay a progress bar and text onto the > image. Is this something we still want to support? There is support for it > in the Java splash handling. The current code that handles the progress is > confusing and needs to be rewritten with an IProgressMonitor like strategy. I think that is handled by SWT code while the native splash screen "only" loads a static file. I think we can keep that. > ### 5. Change in boot code > The splash boot code requires that a splash screen is the first argument > after the java statement. This is different from the current boot code where > this argument is not present. This needs to be figured out (equinox) > together with the ditch of the native code. This could be the switch.
(In reply to Nikita Nemkin from comment #19) > (In reply to Lars Vogel from comment #18) > > Nikita, do you still plan to work on this? > > Sorry, not at the moment. Writing the code isn't the problem, but I hit the > wall trying to build it, let alone test it. > > Upgrading Launcher build process from Win 2003 SDK to Win 10 SDK would help, > but I'm clueless w.r.t. Eclipse build infrastructure. Hi Nikita/Lars, With fix for bug 559865 should unblock your work now.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183962
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183963
(In reply to Eclipse Genie from comment #50) > New Gerrit change created: > https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183962 We are Ok with this patch. (In reply to Eclipse Genie from comment #51) > New Gerrit change created: > https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183963 But with this patch we don't see anything breaking but we don't see the expected behavior as well. Tested with a sample splash.jpg file and launching Eclipse there was no splash.jpg seen.
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183962 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=f64260da79aef3b460ca59c993a996620b89f326
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/183963 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=77d581a19fa8f51448063d43bf3c0548f6dc3160
Launcher has been rebuilt https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a433328627eee648bf628dcc317c5d269f9a3bb8
(In reply to Sravan Kumar Lakkimsetti from comment #55) > Launcher has been rebuilt > https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=a433328627eee648bf628dcc317c5d269f9a3bb8 Are we done here, can this be closed?
Verified on windows with Eclipse SDK Version: 2021-09 (4.21) Build id: I20210815-1800 OS: Windows 10, v.10.0, x86_64 / win32 Java vendor: AdoptOpenJDK Java runtime version: 11.0.10+9 Java version: 11.0.10
Verified on Eclipse SDK Version: 2021-09 (4.21) Build id: I20210816-1800 OS: Mac OS X, v.10.16, x86_64 / cocoa Java vendor: AdoptOpenJDK Java runtime version: 15.0.2+7 Java version: 15.0.2
Tested on Ubuntu as well Eclipse SDK Version: 2021-09 (4.21) Build id: I20210816-1800 Gif format has issue we are unable to animation or tranparency working. on windows and linux.
(In reply to Thomas Watson from comment #56) > (In reply to Sravan Kumar Lakkimsetti from comment #55) > > Launcher has been rebuilt > > https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > > ?id=a433328627eee648bf628dcc317c5d269f9a3bb8 > > Are we done here, can this be closed? Thanks Nikita for the fix, resolving now. Tested on Win10 with .PNG it works fine. But with GIF, image was visible but animation & transparency part was missing. Not sure if I missed something or if it's a bug.
Thanks, Nikita. Nikita or Niraj, please add to N&N.
(In reply to Niraj Modi from comment #60) > > Thanks Nikita for the fix, resolving now. > Tested on Win10 with .PNG it works fine. > > But with GIF, image was visible but animation & transparency part was > missing. > Not sure if I missed something or if it's a bug. I can add transparency, but it will only work on Win8+ and will require a small hack in SWT to make sure progress bar and message stay visible. Did Eclipse drop Win7 officially? Adding animation seems like a waste of time.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184114
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184114 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4a25528ecd2183fe5abb8a3e27f5c89b6385bb2e
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184116
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184116 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=0a3531618c7b14daaada9439a24a0a7bbc036a3e
(In reply to Nikita Nemkin from comment #62) > (In reply to Niraj Modi from comment #60) > > > > Thanks Nikita for the fix, resolving now. > > Tested on Win10 with .PNG it works fine. > > > > But with GIF, image was visible but animation & transparency part was > > missing. > > Not sure if I missed something or if it's a bug. > > I can add transparency, but it will only work on Win8+ and will require a > small hack in SWT to make sure progress bar and message stay visible. Did > Eclipse drop Win7 officially? Yes, IIRC we have dropped Win7 officially. Raised bug 575452 for exploring transparent background images. > Adding animation seems like a waste of time. Sure, I tested with animated images only after seeing attachment 284193 [details]
(In reply to Nikita Nemkin from comment #62) > > Adding animation seems like a waste of time. That is a personal preference. The same can be said for the progress bar. If the animation can be run while bootstrapping Eclipse it would be a cool alternative to the boring progress bar.
(In reply to Wim Jongman from comment #68) > (In reply to Nikita Nemkin from comment #62) > > > > > Adding animation seems like a waste of time. > > That is a personal preference. The same can be said for the progress bar. > > If the animation can be run while bootstrapping Eclipse it would be a cool > alternative to the boring progress bar. Seeing the community interest, raised bug 575455 to capture & explore the possibility of animated images. Hi Nikita: Feel free to pick or you can also share any starting pointers, for anyone to pick and explore. Thanks!
(In reply to Niraj Modi from comment #69) > Seeing the community interest, raised bug 575455 to capture & explore the > possibility of animated images. My 2 cents: instead of animated images, first support HiDPI images (tracked with bug 518138) - the application never gets a second chance to make a first impression Plus: while the Java native splash screen supports HiDPI images, the launcher prevents that the splash is shown (works in PDE, not with the native executable) - see bug 344559.
