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

[Malte Timmermann]

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.

tora - Takamichi Akiyama wrote, On 04/17/09 13:00:
> Hi,
> 
> What current implementation does:
> 
>    vcl
>   ->|       desktop/source/app
>     |------->|
>              |        desktop/source/splash
>              |-------->|
>                        |        sal, OS
>                        |--------->|          disk device / network device
>                                   |---------->|
>                                               = The process is preempted.
>                                               .
>                                               .
>                                               = Disk access is finished.
>                                   |<----------| Interruption
>                                   = turn the process status ready
>                                   .
>                                   .
>                                   = dispatched
>                        |<---------|
>                        |
>              |<--------|
>              |
> 
> So, an attempt of loading a splash image file causes the sleep status of
> process. Until the disk access is finished, the entire process - more
> preciously the thread that made the system call - of starting up
> OpenOffice.org stops.
> 
> Therefore, the idea Mathias mentioned cited below is quite reasonable.
> 
> Mathias Bauer wrote:
>> The splash screen must not be loaded with any office code, it shall be
>> displayed by native code on the platform so that it can be shown already
>> before any Office code is loaded (except soffice resp. soffice.exe).
>> This is our plan to improve the "felt" startup performance.
> 
> 
> I, however, would like to propose anther idea here.
> 
>> I think on all platforms it's easy to load a bmp with native code, how
>> about png?
> 
> How about use of a thread to load and display the splash screen image?
> 
>    vcl
>   ->|       desktop/source/app
>     |------->|
>              |        desktop/source/splash
>              |--. . .->|
>              | create  |        sal, OS
>              |         |--------->|          disk device / network device
>              |                    |---------->|
>              |                                = The process is preempted.
>              |                                .
>              |                                .
>              |                                = Disk access is finished.
>              |                    |<----------| Interruption
>              |                    = turn the process status ready
>              |                    .
>              |                    .
>              |                    = dispatched
>              |         |<---------|
>              |         |
>              |        terminates or waits for join
>              |
> 
> The thread for the splash screen will have to wait until the disk access
> completes, but the main thread can continue to go through the startup process
> without waiting for the splash screen.
> 
> Dividing two different tasks, but somewhat having relations each other,
> into another process is slightly doubtful. That makes slightly difficult for
> the parent process to control its child process. Additionally, in general,
> creating a process is costly than creating a thread. Within a process, we can
> easily to interact and/or control other side., i.e. the status of splash 
> screen.
> 
> Moreover, starting up another process might cause additional amount of disk
> accesses, which would certainly block OpenOffice.org's necessary disk 
> accesses.
> 
> 
> For the comparison bmp vs png,
> 
> $ ls -l /opt/openoffice.org3/program/*bmp
> -r--r--r-- 1 root root 118614 2008-10-01 00:09 
> /opt/openoffice.org3/program/about.bmp
> -r--r--r-- 1 root root 378718 2008-10-01 00:09 
> /opt/openoffice.org3/program/intro.bmp
> 
> $ bmptopnm /opt/openoffice.org3/program/intro.bmp | pnmtopng > /tmp/intro.png
> $ ls -l /opt/openoffice.org3/program/intro.bmp /tmp/intro.png
> -r--r--r-- 1 root root 378718 2008-10-01 00:09 
> /opt/openoffice.org3/program/intro.bmp
> -rw-r--r-- 1 root root  90019 2009-04-17 19:36 /tmp/intro.png
> 
> That would be a balance. How much milliseconds does user's system take to 
> read a disk
> file and how much milliseconds does the application take to expand the PNG's 
> compression.
> Normally, accessing physical devices are much costly than mathematical 
> calculation
> by a processor. I think the use of PNG would get a better performance than 
> use of BMP.
> 
> Regards,
> Tora
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
> For additional commands, e-mail: dev-h...@gsl.openoffice.org
> 

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