Startup Image / Animation support would be nice #151

I want this too!

That would be a nice to have feature.

I think you can easily achieve this right now using two application windows: the first windows to load is chrome-less and contains only a splash image and an asynchronous loader for your assets and main application code for the second window.

You show the main application window when all assets are loaded and DOM of the main application window is ready.

Will try this later today.

mhmm, not exactly what i want ;)

I mean sth. like this:

1. click build app.exe (or move zip on nw.exe).
2. unpack package.json get image
3. unpack show image
4. unpack all
5. launch app, now i can show the window you suggested ;)
6. lauch main app

The timeframe between step 1 and 3 should be less than a half second. The timeframe between 1 and 5 / 6 can be a minute or more with big applications zip files ;) .

yes, if unpack is causing the delay it makes sense. In my case it's the js pre-processing that's causing majority of the delay

super, is there any chance to get this implemented?

I'll implement it in v0.3.4.

thanks in advance :D

this is now likely to slip to the next version

any chance to see this splashscreen stuff soon ? Thanks a lot !

Agh, please don't add this... Splash screens is a huge annoyance to users. OSes already have built-in ways to show when an app is loading, eg OS X with bouncing dock icon.

not all os show that fast and reliant.

the splash was never intended as a must, but is really sensefull as first reaction during loading a big application. One Application of mine has about 20MB of JavaScript + Images and other stuff, so the startup takes a while and a splash was requested by the user ;D

splash was requested by the user

There could be one vocal user that wants it and thousands that don't.

You simply do not catch the point!

The feature I request is to have a startup screen, if the developer want's it! I do not want any enforcement to have a splash screen. I also never asked to force developers to implement a splash screen!

So please stop complaining, do not use this feature and there should be no noticeable change for you! The discussion is senseless! - This is the last answer you get from me!

I'm just giving you a users perspective on it. I have no say in what gets implemented or not. I just feel there are more important features that could be added than those which will degrade the user experience when used.

ok, than sorry.

i had up to 30 secs of loading time, and my users asked me if the application dies during startup, as windows does not show any good indicator, which states, that the application is still loading :dancer:

So from my perspective the splash screen is an improvement for the usability.

I also agree to your opinion, for the case, that the application can technically start instantly. If possible loading should be as fast as possible, but the user should also get an idea on how long loading will take.

Has any progress been made on this option? I too have an app that takes some time to load and my client would like some indication that something is happening so their users don't just keep clicking till something happens.

I vote for that too. A stratup image would be great for my game "launch time" ^^

I have the same problem - my zipped app has smth around 10MB and until it's unzipped nothing happens, no indicator is shown under windows, so a splash screen or anything to show user that application is starting would be nice.

-1 - if the user is concerned if the application is starting, they can check a task manager, ps aux, or any number of process listings.

Damianb, do you really think most "average" users know of such things, or have the patience?

Many are patient enough for applications to load, yes. Please stop with the passive-aggressive behavior.

My apologies if I came across "passive-aggresive" damianb, I was genuinely curious if you believed in what you had suggested. Personally I disagree with you, but that's my opinion as I don't currently have data at hand to support it so let's not argue over it.

I would rather discuss the issue that some of these apps can take a long time to load with NO "apparent" indication that anything is happening. Rather than ignore the user experience and hope they know how to find out if anything is happening, risk losing their attention all together or worse frustrate them, I would like to take action to make their experience better.

I believe we need a solution that provides A) Some indication that the app is loading and B) A splash screen to brand your app.

This is actually does not need an argument, this should or have built-in upon building node-webkit. Every Enterprise or how simple it is and it contains lots of unpacking, splash or branding is always an option.

as it should not be a must, i can't see, why someone is fighting this FEATURE. All my customers where is used node-webkit asked for any indicator during the loading of the Application.

why not just provide some lightweight startup page with loading indicator, and load heavy resorurces async?

take a look here, it's the unpacking, which causes the delay.

https://github.com/rogerwang/node-webkit/issues/151#issuecomment-10157354

because :

• even if our first page is very light, node-webkit can be very slow to load for heavy .nw/.app files.
• it would be a huge pita to handle correctly from html/js code ...

ok, got it, i think it could be possible to implement it simmilar to how window icon is done.

also, api for displaying some text over splash image would be also nice, but this is optional.

Alright, let me explain my position here; nobody's considering the consequences of such a change here it appears.

This just needlessly complicates nw startup IMO and adds to the problem of creating an executable which, by the way, means you still have to partially unpack the zip to get the image itself (after unpacking enough to get the manifest file).

Let's assume the feature is implemented, and you have your splash image specified in the manifest file...

So, now you've just modified the program launch significantly and made it even worse for how much it has to do.

1. run nw executable
2. unpack app.zip partially
3. read manifest file (determine splash image)
4. unpack app.zip partially (again)
5. read splash image
6. render splash image
7. unpack REST of app.zip
8. launch application

In adding this "feature", you're adding quite a bit more disk I/O events, some processing (depending on how heavy the compression is), and it all has to happen synchronously in order to just display a pretty picture to let the user know it's starting. Before, we just have to accomplish steps 1,7,3, and 8 (in that order); now we've added three more steps and are further burdening ourselves with the unpacking problem anyways! (woo for being disk and CPU bound again)

If you want a splash screen, find or write a chain loader that will handle that and launch nw at the same time; that way, it doesn't hurt everyone's performance. Otherwise, you're creating a major performance hurdle for everyone to run into.

I've also just had a thought about a potential solution to the root problem: startup is slow due to unpacking of the application...which leads to the deeper question, "why unpack at all?"

Ref #814; perhaps use of tarballs would be ideal, since there's no compression at all within a tarball (compression happens afterwards to the tarball). This would reduce the amount of processing, and depending on the unpack/read mechanism, may reduce disk I/O.

Thanks @damianb for this interesting insight.

A few leads that may not slow down everyone :

1. Generic startup image
   • A generic and small "Loading" screen/indicator shown by nw while unpacking. I think that would already make many people here quite happy to have "any" visual feedbak :)
   • Could be changed by people willing to recompile nw for their needs.
   • Could be using application "icon" (found in exe for windows, info.plist on osx ...)
   • Could be enhanced with percentage if possible ...
2. An external Image file shipped "outside" the "zip"
   • This doesn't work if you provide the .nw file alone, but i think most people provide "full package" including nw and zip (otherwise fallback to 1. ?)
   • Can be a staticly named file like "splash.png/svg/whatever" and stored :
     • At the root of the .app folder for osx
     • alongside with the exe and dlls for windows
     • alongside with the pak/so/nw on linux

yeah, with convention over configuration this should be easy and fast to solve. As far as i know it's also possible to test if a zip contains a file without unpacking. So if a startup image exist (either in the zip or beside) show it, if not do it as it's done now. (for me, it's not important to configure the image in a textfile, a convention would solve my problem as well).

@kaystrobach that still leaves at least five different fs checks within the zip - (png|svg|gif|jpeg|jpg) - could drop gif but that's still more work within the zip file and it's a tripping point since you're adding a "magic" behavior based on filename.

not true, you can IMHO simply define a convention e.g. startupAnimation.png. Many systems rely on conventions, so why making things complicated? Showing just png's is also a way faster than loading an svg parser or similar stuff.

ironic I mean we could also provide a mp4 file, which is played in sync with the progress of loading the app (10% unpacked, forward to 10% of the movie playback, and so on) ... this way anyone may create custom startup animations. /ironic

@kaystrobach I'm just trying to be objective and help work towards a better solution to the problem at hand; there's no need to get rude.

i don't wanted to be rude!

I saw very good implementations of the mp4 startup animation stuff, so it's not an unrealistic solution. An mp4 is just a bunch of keyframes and differential images which can be used to solve many problems :D. But in case of this discussion this is not rude anyway.

What i can't understand is, we talk about a checks of existance of a file in an archive.

As far as i know, this is easily and extremly fast possible with most zip implementations as ZIP has a directory index. Even on the commandline this is possible. 7-Zip uses this to let you browse the archive without extracting it, as well as other tools.

unzip -l archive.zip

http://superuser.com/questions/462788/read-the-contents-of-a-zipped-file-without-extraction

In numbers: Unzipping a TYPO3 6.1.0 source Zip (http://prdownloads.sourceforge.net/typo3/typo3_src%2Bdummy-6.1.1.zip?download) takes 10 secs. Using the above command takes below 0.01secs outputted to a tty (can't measure more precise without building a real programm)

So it's not a real additional IO operation, but during the opening of the Archive you iterate over the index and look if there is a match in the filenames - this should be pretty fast, and should not add a noticeable drop in performance, as it's just a string comparision.

Using the above command takes below 0.01secs outputted to a tty (can't measure more precise without building a real programm)

Tip - Install appropriate package to get the "time" command, use that for measurements instead (iirc debian uses time for package name? arch has it under time from what I see, and bash has a potentially less reliable builtin, and so does zsh)

e.g.

:katana@solanine ~/
$ time sleep 2
sleep 2  0.00s user 0.00s system 0% cpu 2.015 total

ed: ooh, I was using zsh's time function. /usr/bin/time seems to be a bit different.

:katana@solanine ~/
$ /usr/bin/time -v sleep 2
        Command being timed: "sleep 2"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: 0%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 648
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 206
        Voluntary context switches: 2
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

I really do wonder though why the compression here. It seems the primary need is for an archive; hopefully tarballs can be looked at instead and just rid us of decompression entirely.

I really do wonder though why the compression here. It seems the primary need is for an archive; hopefully tarballs can be looked at instead and just rid us of decompression entirely.

Then you will have a package that is slower for everyone to download, just to provide a startup image ...

I think compression could really matters on some projects and it would be a bad idea to remove it to gain this functionality. (for example i had to store both osx/windows versions of my project on a DVD and size mattered, download/storage size could matter too ...)

Then you will have a package that is slower for everyone to download, just to provide a startup image ...

Pack the entire installer, unpack on initial installation? Having the user decompress a zip initially is nowhere near as bad, and most can figure out how to extract it out to run it tbh. And for the windows users that don't, there's 7zip self-extracting archives.

I dont know if it's doable or worth it, but maybe it is possible to extract contents into memory? For projects with heavy resources you still need to unpack, but but for those with <50MB size it coud speed up things.

Maybe it is out of topic, but IMO extracting contents in temporary folder is somewhat uncool,,, we already can protect our JS with v8 snapshot, but what about rest things? is it possible to create some kind of container in the memory so nw can refer to resources there?

@damianb

Let's assume the feature is implemented, and you have your splash image specified in the manifest file...

So, now you've just modified the program launch significantly and made it even worse for how much it has to do.

1. run nw executable
2. unpack app.zip partially
3. read manifest file (determine splash image)
4. unpack app.zip partially (again)
5. read splash image
6. render splash image
7. unpack REST of app.zip
8. launch application

In adding this “feature”, you're adding quite a bit more disk I/O events, some processing (depending on how heavy the compression is), and it all has to happen synchronously in order to just display a pretty picture to let the user know it's starting. Before, we just have to accomplish steps 1,7,3, and 8 (in that order); now we've added three more steps and are further burdening ourselves with the unpacking problem anyways! (woo for being disk and CPU bound again)

The current state is not quite 1, 7, 3, 8. The app.zip is unpacked entirely, and thus it's more like 1, (2+7), 3, 8.

The suggested behaviour adds steps 4, 5, 6 (unpacking and reading and rendering of the splash) and separates steps 2 and 7 (the manifest is unpacked and read before anything else).

The steps 4, 5, 6 are going to introduce some I/O and CPU burden indeed. The idea behind this suggestion is to pay this price (willingly) for an improvement of the user's perception.

Perceived speed is more important than actual speed, and the user is much happier when something starts happening instantly. The existing delay before an actual application start is prolonged slightly, but the user is entertained through the whole delay.

The suggestion is given under an assumption that user's “look, there's a splash!” experience lasts longer than steps 4 and 5 and 6 combined, and thus the benefit is worth its price.

The suggested practice can also be easily made optional (when the manifest does not mention a splash, the 4+5+6 steps are not happening).

Then you will have a package that is slower for everyone to download, just to provide a startup image...

Pack the entire installer, unpack on initial installation? Having the user decompress a zip initially is nowhere near as bad, and most can figure out how to extract it out to run it tbh. And for the windows users that don't, there's 7zip self-extracting archives.

If you pack the installer and unpack on the initial installation, why use any archives at all.

Let the installer make a directory and populate it with unpacked files, and use nw foldername (most likely, nw .) to run your application.

That would prevent the need of any unpacking at application start time.

Hi all,

I've finished an implementation of a new distribution method I think will fill this need quite well. Instead of having to unzip all of the resources on boot each time this stores all distributed files as internal resources and creates a cache look up table (on demand).

It reduces the node-webkit bootime with 200MB of resources from ~33 seconds on a 1.8ghz processor to ~1.2 seconds. It also doesn't break existing implementations/distribution methods.

Downside is it would most likely need to have someone create a open source build system. (It's essentially a magic key + file name + file size + data concatenated and appended to either Content/Resources/Package in MacOSX or the end of the executable on Windows).

Hope it helps.

https://github.com/trevorlinton/node-webkit/commit/3c162a80ae92db5a91f3baee70b97a790dd43eef

I should also mention with this method all content/resources are unpacked in memory and never written to disk.

wow, amazing! what about debugging? are all resources source files visible in dev tools? anyway i hope it will be merged

@Dream707, yes. Instead of using the default file:// (which uses the old methods) you just switch your protocol prefix in the package to embed://. This tells node-webkit to look back inside of its own resources and returns back the file pointer of the resource (and length) to chromium. This keeps the files from ever being written to disk or requiring them to be unpacked on boot. It also uses chromium caching so the files need to be read from the resources only once.

Preventing disk IO significantly improves speed, in addition the files can be gzipped or left unpacked depending on your preference. This also helps protect code (it just makes it a little more difficult for people to crack) rather than current methods of unpacking the zip file to a temporary directory.

Debugging/dev tools still work perfectly find, it just shows that the html/js/whatever file is from embed://YourFile.html rather than file://<some path to a temporary directory on your host>/YourFile.html

I passed it on to Roger who said he'd take a look. If anyone is willing to make a shell script for all platforms to create bundles using this method that would be great (I'm really pressed for time right now otherwise I would). The format is in the code I committed but if you have questions let me know.

@trevorlinton What's the memory footprint look like, though? I'm quite curious of the potential impact.

@damianb The files themselves aren't cached in memory (with the exception of chromiums normal caching mechanisms/policies) however the table that points to where the files begin/end within the package are cached and is fairly minimal. (You can calculate the size of the cache table, its 64 bits (file size), file name (at most 256 double bytes for utf8, so 512 max) and the magic key twice which is 14 bytes. So total: (22bytes+512bytes) * number of files in the package.

I ran it on a package (as a test) of 300 pdf's totaling around a gigabyte package and there was no significant change in the memory footprint.

This method is commonly used for large file packages, similar to how grit or windows pe resource tables work.

@trevorlinton Sounds good; are there any other potential downsides that you can think of, other than packaging?

@damianb Two:

1. In order to package things up a custom build tool will need to be used.
2. You'll still need to store your package.json in a zip file (either as a app.nw or appended to the executable). The only way to get around this is refactoring the original package loader which i'm hesitant to do because it may break existing versions of node-webkit and require a lot of coordination and effort. However from what I can tell node-webkit really doesn't break a sweat unpacking a few bytes before it loads.

That seems about it. I should add I added support for range requests to the embed protocol (I may be wrong, but I don't believe traditional file:// protocol supports this). Supporting range requests allows for chromium to only load/cache portions of a file rather than having to load the entire file into memory. For example, if you load a PDF it will read only enough to render a certain portion of pages. As you scroll down (or if chromium feels it has more memory to burn) it will load (and unload) only the data that is needed to render at that moment. This significantly helps with memory foot prints.

how long it takes to build project with 200 MB of resources with this type of packaging?

ps. maybe it is possible to have partially prebuild components to reduce compile time?

@Dream707 It's fairly quick, not much time at all. I think i'll write together some nodejs javascript to package items up. With that said i'm looking into trying to hit two birds with one stone with Issue #843. This may require holding off on a release as it requires the new method/build tool to properly update and stamp image sizes/check sums and windows PE header files to avoid antivirus software from blocking node-webkit.

Hopefully since I have a good portion of the work done (and I don't have to deal with reallocation tables in Windows PE headers) it shouldn't be too hard and would make node-webkit/normal C++ windows executables indistinguishable.

@rogerwang any news on supporting this type of packaging in 0.7.X ?

any updates on this? @trevorlinton @rogerwang

@Dream707 I've implemented it in Tint, the code is in my repository if @rogerwang wishes to implement it. I'd be willing to put together a diff patch for node-webkit if there's interest in pushing this up stream.

You can checkout tint at www.trueinteractions.com, however its commercial support for node-webkit and not necessarily the same thing as node-webkit.

Let me know what I can do to help get this pushed into node-webkit, as i think it would add alot of value.

yeah, thanks for the update, one more quetstion, how is build process going? is there need for any additional tools/scripts to pack/build your app?

@Dream707 I'm refactoring the tint compiler to pull out the packager code (written in javascript). Once i'm finished i'll post it to this thread and the embed protocol commits. This would allow someone to build a nodejs commandline script or a desktop gui written in node-webkit to produce packaged applications.

The script also includes "Stamping" and manifest tools to write manifest data and change the icons on windows and macosx from a 512x512 png file. This required writing a javascript program to parse through windows executables..... if you want to see that horror, take a peak: https://github.com/trevorlinton/node-windowsexe/blob/master/windowspe.js

@trevorlinton that's awesome, but we still don't know what @rogerwang thinks about it. Maybe it's better to start a new issue, since it's not about "Startup Image / Animation support" anymore?

@Dream707 The problem of animation support or a "Loading screen" unfortunately doesn't have a simple solution. Reason why is unextracting the contents using the previous packaging method is too much time. Creating support for a loading or animation to appear while the extraction occurs is also impraticle, it becomes a chicken and egg problem since the animation/loading screen resources can't be accessed until the contents are unzipped.

With this new packaging method it removes the time it takes for node-webkit to load dramatically by only grabbing resources needed as requested, essentially both eliminating the need for a load screen, while also allowing roger or other contributors to create loading screens prior to even node-webkit/chromium booting.

While agree the bug is filed from a user needs perspective the solution is highly dependent on an entire new packager.

i can't understand the problem.

Basicly you need to do:

• unpack settings (can be left out by a convention)
• unpack image / indicator
• show image
• unpack all the other stuff
• launch application

I know that this may take some milliseconds longer, as the ZIP Index needs to be checked if the file defined in your convention exists - but luxury and speed do not always match

@kaystrobach with new packaging system there will no need to unzip anything at all, it will be just embedded in executable as a resourse that can be accessed by special pseudo-protocol.

I solved this issue with using "document ready" (jQuery) and then removing or hiding your "loader image" after everything is initialized. You even can wait for the event when window is loaded https://github.com/rogerwang/node-webkit/wiki/Window#loaded

@Dream707 nice, if that is solved with new packaging, i'm fine @mclckr it's not about loading the app, but about unpacking it, during the unpacking there is no window available ...

@kaystrobach you can get basic idea from latest 5-7 trevorlinton's comments

If you want a startup image, it should be left out of the app.nw if you want to put it in app.nw you'd need to open the zip which is 90% of the work anyways. The only way this would work is the following

Have some sort of addition to your manifest file

"startup": "image.jpg"

In the files before it does the unzipping of app.nw create a frameless window with the image.jpg as the background.

Do the unzipping, and when it's done close the startup window and open the regular window.

The same sort of thing for animation, but this would be better once transparent windows are finished.

@dubcanada The manifest is located within the zip file unfortunately, in addition this would require keeping the start up image.jpg outside of the zip file next to the executable or package which isn't ideal. I suppose the idea is to have a longer term fix than a short term patch.

I've actually finished support for transparent windows and the new package/embed. I'm waiting on @rogerwang to see when/if he wants to incorporate these (the transparent windows does not yet support linux unfortunately).

A predefined filename could be a solution. Such as always looking for splash.png in the same directory where .nw package resides.

If I were the one developing an app, I would want a convention, not a configuration.

splash.png is fine.

I also would NEVER use it myself.

For those who downloaded or want to use the embed:// protocol the source is up and the compiler/packager is at:

https://github.com/trevorlinton/node-webkit/blob/master/tools/compiler.js

@trevorlinton compiler should respect case if I need window/mac/linux - only build something like build.data.Platforms = ['win','mac','linux']

it would be cool to be able to use this compiler as node module, like

var nwCompiler = require('./compiler'); 
nwCompiler.run(config);

currently got stuck with error:

{ [Error: ENOENT, no such file or directory 'd:\Projects\nw-compiler\Resources\Runtime.app']
  errno: 34,
  code: 'ENOENT',
  path: 'd:\\Projects\\nw-compiler\\Resources\\Runtime.app',
  syscall: 'stat' }

p.s. is it working with original nw? or it should be builded from your sources?

@Dream707 To work you'll need to build from my repo or grab my binaries, Roger hasn't pulled in the sources yet for the embed protocol but you can find NW-compatible runtimes at http://www.trueinteractions.com/trial.zip. Within the zip there's a "Resources" folder, just copy out those items into the same folder as compile.js. Or you can build from my sources @ http://github.com/trevorlinton/node-webkit.

As for the script, it isn't built as a nodejs module, however if anyone cares to wrap it I doubt it'd be too hard. It only needs to export a handful of functions. PS, i only distribute mac/win runtimes, but you can compile out linux builds as the embed:// protocol isn't platform specific.

@trevorlinton I don't see any opening pull req from you?

@rogerwang Oops. I'll put one together today.

@rogerwang It would be vastly easier for me to bundle the transparency support + embed protocols into one pull. The transparency doesn't support Linux but in another forum someone said it would be trivial for them to add. There's currently just stubs for the linux version for compatibility, is that ok?

@rogerwang

I've sent a pull request that has support for embed:// and transparency support for Mac/Win with stubs for linux to both nodewebkit and nw-chromium projects.

@kaystrobach Why not use a frameless window as the splash screen? You can put anything you want in the splash screen. Not just static or animated images.

1. Simply hide the main window when starting up by setting show to false in manifest.

{
        "window": {
              "show": false
        }
}

1. Use following code to show a frameless window before loading resources:

var splashwin = require('nw.gui').Window.open('path-to-your-splash-page.html', {
        'frame': false,  // frameless
        'position': 'center', // centered
        'always-on-top': true // always on top
});

3.And finally when everything is loaded, hide the splash window and show the main:

splashwin.close(true);
require('nw.gui').Window.get().show();

i already described, is not about the time after unpacking, that's an easy task, it's about the time during unpacking. But as the packaging should have changed away from zip, this should be solvedable now.

here is still described to use zip files - https://github.com/rogerwang/node-webkit/wiki/How-to-package-and-distribute-your-apps so what's the right way?

I just hope that @trevorlinton 's patch will arrive one day and we'll see more intelligent packaging system

Hello, a splash screen would be really nice. Looking forward to that.

+1 on the new packaging.

+1 for the new splash screen especially for windows. User clicks on the app and keep clicking thinking what exactly is wrong because he is not able to see anything. Not good user behaviour.

For those who can't wait for the new unpacking: I just wrote a small c++ app that loads nw.exe as a unhandled child application. During the unpacking event the splash waits for special Tags in the Clipboard and renderes a progressbar with the inputs. When the loading is finished, i closes itself.

So you have to modify your node-webkit app: just use the JS-script which will give you the functionality to paste stuff to the clipboard with https://github.com/rogerwang/node-webkit/wiki/Clipboard

to be honest: the current release code-release status is pretty massy, it's more or less a copy paste of different sources. But it works on Win XP-8.1 without .Net.

https://github.com/the86freak/Splashscreen-Clipboard

+1 for unpacking process tracking, it would be even nicer to know the percentage of unpacking. but anyway the splash screen is wonderful for the first step.

For Windows - Enigma Protector has a built in splash screen that can be set, if you are already using the Enigma Virtual Box to combine your .dll with the .exe this will be an easy transition.

You could also just have Enigma include the file structure instead of compressing it with .nw. I would also recommend that you combine and compress your JS as you would with serving them on the web.

+1 I have a very large app, and it takes sometimes minutes for it to load. It is very confusing that nothing shows up until the entire app is loaded. I would love to see a loading screen with progress if possible.

So as I understand it correct, the problem is while unpacking the zip archive and for this there is no native solution in node webkit to see a splash screen right? We have to use Enigma for example or whatever?

yes - will never understand that ...

wow.. this topic has more than 2 years and still no solution for a such important thing?? i wished i was a good programmer!!

+1 for the splash screen!!

@uiliw what should i say ;) ... yes i switched to nightrain finally https://github.com/naetech/nightrain, this one needs no startup image, as it starts faster (no unpacking needed)

hmm.. this has no support for ajax calls.. wont fit for my needs! NW is still the best solution. As my app has 250mb, it take a while to unpack in windows.. thats why i need a splash screen just to tell the user that something is going on before it start.. i just discovery that the app Popcorn-Time is built in on Node-Webkit too, and it has a loading page before start the app.. ill take a look and try see how they did it!

@uiliw you don't need to pack it into zip -- NW now supports another "package" format: just put NW files in your tree.

@rogerwang yeapp.. i just found out this!! and this really improved a lot!! Thanks @kaystrobach this comment has the answer for what you was looking for!

@rogerwang is this already part of the documentation about "how to package and distribute your app?"?

@Chris2011 yes it is! .. second item

But for both I have to create a zip, as I understand it right oO.

Still no splash screen? This makes n-w sooooo unfriendly on windows....pretty much everyone assumes the apps have hung or dies.

Check #514 it's probably more to-do with slow unpacking of zip.

Still no splash screen? This makes n-w sooooo unfriendly on windows....pretty much everyone assumes the apps have hung or dies.

— Reply to this email directly or view it on GitHub https://github.com/nwjs/nw.js/issues/151#issuecomment-94042285.

You can mimic a splash screen, as @ghostoy suggested above. For Fenix Web Server, I don't package everything in a zip because it is too slow & unnecessary to unpack every time the user opens the app. The source is available on Github if you want to see an example.

Are there issues with @trevorlinton 's patch @rogerwang ? It seems to do pretty much the job.

@mib4fun which exactly patch are you referring to?

@trevorlinton made a patch for adding the "embed://" protocol to node-webkit. EDIT : https://github.com/nwjs/nw.js/issues/151#issuecomment-27315582

+1 for the splash screen!!

+1 A custom splash would be nice but a simple frame less window stating it is loading would work just fine.

+1 For the splash screen I am make one English Learning App Which content a videos. means my zip size is very big. And its take almost 3 Mins to launch a application so i need to display splash screen there. And if any other way to do this please help me.

+1 for Splash screen!

just to remind some of you guys here who can't wait and/or read all posts: some solutions have been proposed:

basic c++ with custom image and loading-bar: https://github.com/nwjs/nw.js/issues/151#issuecomment-39712618

Enigma Zip: https://github.com/nwjs/nw.js/issues/151#issuecomment-44186498

or no zipping at all: https://github.com/nwjs/nw.js/issues/151#issuecomment-65222370

-- not a real solutions, but an idea frameless window https://github.com/nwjs/nw.js/issues/151#issuecomment-30910328

@the86freak Thanks :+1:

@ghostoy / @the86freak don't forget to add the `"toolbar": false`` when opening the splash, otherwise on windows you get that nasty location bar.

// opens the splash
var splashwin = require('nw.gui').Window.open('splash.html', {
  **"toolbar": false,**
  'frame': false,  // frameless
  'position': 'center', // centered
  'always-on-top': true // always on top
});````

@the86freak The problem with the frameless trick is it still requires NW.js to unpack everything before it can display the frameless window. The unpacking is the main reason for the delay. So I wouldn't list it as a solution as the problem of loading time will still exist and the frameless window won't load until this loading time ends.

@baconface right and thanks, I edited my comment

+1 for the splash screen

+1 for the splash screen. More than 3 years for this issue and still not solved!

+1 for splashscreen

Stop using package.nw then your nwjs will start very fast. By the way Electron does not have this issue with their uncompressed asar archive, so maybe nwjs should do the same...

I have packed it with Enigma VM. The Problem are the mass of files in node modules. For example when using emailjs.

+1

I kust switches to electron becuse of this ...

+1 for splash screen

With a 300mb app (nwjs 0.17.4) loading time on Win7 x64 is ~30-35 seconds even when my zip file is uncompressed. This amounts to a horrible user experience.

Splash screen is a super simple solution to a problem many people have had for apparently 4 years and people who don't need it can simply not use it.

+1

Splash screen is still a useful and needed feature that help users to wait during application startup/unpacking/loading/rendering : just consider it is well used by Microsoft for Office programs!

Another +1.

passed 4 years and nothing, for those who are looking for an (better) alternative here it is: http://electron.atom.io/

+1 for the splash screen during unpacking

Hi Keshav, please read https://github.com/nwjs/nw.js/issues/151#issuecomment-10157354 have fun ...

+1

I also would like to identify a justifiable reason this feature should be implemented.

Factors outside of our control require our NW application to be delivered on a network share drive and executed by the customers on windows computers directly from the network drive. Each customer has varying levels of connectivity and can take a long time for a basic nw.js Hello World application without compression to show the first sign of something happening. Unfriendly customer policies do not allow users to copy the entire to their local computer to execute locally.

I created a quick experiment to highlight the issue for field deployments of the absolute minimum NW.js application. This assumes no unpacking is required

Starting with the NWJS-v0.23.3-win-x64.zip download, I added the following index.html file and removed unused *.pak files from the locales folder.

<!DOCTYPE html> <html> <head> <title>Hello World!</title> </head> <body> <h1>Hello World!</h1> We are using node.js. </body> </html>

The resulting application is ~127MB in size.

It appears that at least the (nw.exe & nw.dll) ~94MB must be downloaded in its entirety before any window is displayed.

Measured on a 100 Mbit/s LAN, the average time before displaying the hello world window was approximately 10 seconds.

Measured on the same LAN connected via wireless, the average time before displaying the hello world window was approximately 60 seconds.

These time periods would not be a problem if a splash screen was first loaded to indicate that the application is loading. Is there is plan to breakup the the application components in a manner that could support downloading the minimum to display a splash screen prior to loading the rest of the nw components and the main application? Otherwise, does anyone have a workaround for displaying an external splash screen via a sister application that is removed after the NW app is loaded?

Thanks. BTW, great work on NW. It is awesome and your work is much appreciated.

+1 for the splash screen verry handy !

+1 for the splash screen

+1

+1

+1

spash!!!! screeen!!!

+1

+1

+1

@boostio funded this issue with $20. Visit this issue on Issuehunt

@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt

@d3portillo has started working. Visit this issue on Issuehunt

@d3portillo has stopped working. Visit this issue on Issuehunt