Re: [gsl-dev] replace the .bmp splashscreen

[tora - Takamichi Akiyama]

Hi Malte,

I see the requirements and benefits which comes from the native code.

For PNG/BMP consideration, as you might have noticed, I also took into
account of loading a library file which deals with PNG's compression.
What I thought, but didn't mention in the previous mail, was that the
library file would be used for handling other PNG files. So, sooner or
later, the library file has to be loaded for OpenOffice.org' s operation.

What I mainly thought was how to reduce the entire startup time of
OpenOffice.org, not how quickly the splash screen appears.

Now I understand that the quick appearance of the splash screen is
one of the important factors.

One possible implementation that might help is to use the same library
file that OpenOffice.org also uses. The process has to load several
library files to display the splash image. That means the contents of
the library files has been already loaded into OS's physical memory
as a replica of disk device when the OpenOffice.org's process is about
to start. If the both process share the same library files, some of
the files could be loaded ahead in the similar way as 'pagein' does.

Loading a shared library file whose size is more than 1MB and a PNG
file in 90KB might be much more costly than reading a .bmp file in
the size of 378KB and a small-sized code. However, if the shared
library is also used by soffice.bin, a room for consideration would
still remains.

I, however, would like to leave a decision to you and your team.

Thanks a lot,
Tora


Malte Timmermann wrote:

Hi Tora,

thanks for these investigations :)

Wrt thread/process: We would like the splash screen to appear ASAP.

I think your approach can help avoiding some unnecessary delay (really
measurable?), but it will not help for seeing the splash earlier than
nowadays. (You don't avoid all the slow library loading)

Assuming that we want to completely avoid VCL bootstrapping before
showing the splash screen, and use native code, as few code as possible:
Your PNG/BMP consideration also needs to take into account the load time
for the extra filter code, which might mean 1 or more additional
libraries, but at least some more extra statically linked code.

Malte.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
For additional commands, e-mail: dev-h...@gsl.openoffice.org