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

[tora - Takamichi Akiyama]

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