> I have noticed the following -
>
> I also observe the following when I run the java run-time envs on
> both the machines. The brutus board takes about 10 minutes to display
> the first start-up window of any java application while the same
> code runs almost instantaneously on the netwinder. Could this be
> because of the differences in the FPEMs ? I havent gotten around
> to switching them yet. So, any pointers would be appreciated.
>
I don't believe this difference is solely an FPEM issue.
On Brutus, the display uses 8bpp for a max of 256 colors. When
the JVM is launched with <=8bpp, it calculates a dithering cube
in order to find the 256 best colors. I suspect the dithering
cube logic is entirely floating-point calculations. Most likely,
the Netwinder is using 16bpp or higher mode and the dithering
cube is not necessary. Note, this is mostly theory, but if you
have the JVM source you can take a look at
javasrc/src/<arch>/sun/color.c.
I am surprised it is taking 10 minutes. On my SA1100 board
running at 206MHz and using the nwfpem, it consistently
takes 4 minutes to lanuch a graphical app. Non-graphical
java apps run immediately.
Finally, I assume you are using the JRE binaries that Corel
ported for the Netwinder. Unfortunately, Corel did not make
the source available and Rebel.com appears to be trying to
wipe their hands of the entire package. A common way to
fix the dithering cube problem is to modify the JVM to save
the color cube values to disk and reload them on later executions.
If we had Corel's patches to Sun's JVM, this would be simple.
If anyone has successfully ported the JVM to the ARM using the
Blackdown linux patches (or other patches), please let me know.
Thanks,
Eric
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
