Menneisyys
07-15-2005, 04:19 PM
Over at iPAQ HQ (http://www.ipaqhq.com/forums/showthread.php?t=19783), a Java-enabled browser was looked for for displaying and controlling the animation here (http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.kmvx.shtml).
As in the last two months two new Java-capable browsers (JVM stands for Java Virtual Machine and being Java-enabled means that the given browser will (?) be able to render Java applets) have been released (Thunderhawk 2.1 and NetFront 3.2), I’ve jumped on the chance to make some new comparison tests, mostly because
1, this applet has more advanced GUI components – that is, a scrollbar – and not just buttons/menus, unlike in my previous tests. I wanted to check out how Thunderhawk (TH), which, unlike the other Java-enabled browsers, uses strictly client/server (c/s) Java rendering, fares againts the competition (it failed).
2, it also uses an applet window bigger than the QVGA, and even the VGA screen. It was a big problem with the Jeode PIE plug-in, back in 2001, that it wasn’t able to render bigger applet windows than QVGA. Therefore, I wanted to know how the latest JVM’s fare in this area. (All passed.)
Please note that this is the nth instalment in my Java-on-the-Pocket PC series. You may want to read the following previous instalments; just to name a few (it’s the best to make a generic search on ‘Java’ on my nick in Pocket PC forums):
Compiling/editing Java on the PPC (http://www.pocketpcthoughts.com/index.php?action=expand,40880)
Create your own custom word dictionary - a working, free solution (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41049)
Using Java on the Pocket PC - the complete tutorial (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41081)
Now, for the tests:
NetFront 3.2 (http://nfppc.access.co.jp/english/):
It displays the applet, everything works (to a certain degree), BUT:
on VGA devices, in the standard, default SE VGA mode, and even in forced VGA mode, it uses low resolution in the applet area:
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJava.gif
Default SE
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJavaForcedVGAChopped.gif
Default SE, with forced VGA mode
As you can see, NetFront 3.2 miserably failed at the forced VGA mode: it just chops off half of the applet area. Therefore, never use NetFront in the forced VGA mode to render large applets!
In native VGA mode (the one that can be switched to with SE_VGA or OzVGA), everything worked just fine:
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJavaNativeVGA.gif
I’ve also faced another problem (which was the same with version 3.1 of Netfront, which had a completely different JVM): the memory and the CPU leak. Even horizontal scrolling of the applet are was almost impossible while displaying it, due to he memory leaks and the CPU usage; after exiting NetFront, the JVM still remained in the memory, totally slowing down the entire device. That is, if you use the JVM in NetFront 3.2, you most probably end up reseting your PDA after your Java session. This problem is particularly prevalent in native VGA mode.
I’m not very happy to say that the JVM in NetFront is still buggy…
Pocket Internet Explorer with the CrEme 4.00b8 (http://www.nsicom.com/Default.aspx?tabid=159) PIE plug-in:
It’s working great! Much better than Netfront 3.2 because
1, it’s Hi-res even in SE on VGA devices
2, is completely removed from the main memory after you exit, unlike the NF3.2 JVM.
http://www.winmobiletech.com/072005RadarJavaTest/Creme400NOAARadarJava.gif
A bit of warning: CrEme 4 blindly overwrites (instead of appending to it!) [HKEY_LOCAL_MACHINE\Loader], so, your all previous so-called “System path” settings will be gone! Please see for example this thread (http://discussion.brighthand.com/showthread.php?s=&postid=773927) on the System path and its usage. Also, as with the older (3.26) version, the installer EXE file won’t be able to execute on desktop Windows computers that have localized \Program Files directories (for example, \Programme with German Windows).
Thunderhawk 2.1 (http://www.bitstream.com/wireless/products/pocketpc/index.html):
Well, unfortunately, the c/s communication and plain image reload model of the TH JVM certainly sucks at both animation, bandwidth usage and, certainly, GUI control, as I’ve predicted here (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=40983) and, later, in my first “real” TH 2.1 test, confirmed here (http://www.pocketpcthoughts.com/forums/viewtopic.php?p=352806). While the “Set Animation Speed” slider can be dragged without problems in other browser + JVM combos, in TH, as you may already have guessed, it’s impossible to do this. Why? Because you only get an image, and not real, client-side GUI controls. This means you can only slide a slider one step at a time, in a very time (and bandwidth-) consuming manner. There is no way of dragging sliders at all!
Furthermore, it’s QVGA on VGA devices, and, what is more, the picture is skweezed – that is, you will hardly be able to make out what is written on the map:
http://www.winmobiletech.com/072005RadarJavaTest/TH21NOAARadarJava.gif
A quick TH tip never published before: the app creates a \Windows\winsys.bat file to store user information. If you remove/relocate it, you’ll be able to log into Thunderhawk from another user account – it’ll start with defining the new screen again.
As in the last two months two new Java-capable browsers (JVM stands for Java Virtual Machine and being Java-enabled means that the given browser will (?) be able to render Java applets) have been released (Thunderhawk 2.1 and NetFront 3.2), I’ve jumped on the chance to make some new comparison tests, mostly because
1, this applet has more advanced GUI components – that is, a scrollbar – and not just buttons/menus, unlike in my previous tests. I wanted to check out how Thunderhawk (TH), which, unlike the other Java-enabled browsers, uses strictly client/server (c/s) Java rendering, fares againts the competition (it failed).
2, it also uses an applet window bigger than the QVGA, and even the VGA screen. It was a big problem with the Jeode PIE plug-in, back in 2001, that it wasn’t able to render bigger applet windows than QVGA. Therefore, I wanted to know how the latest JVM’s fare in this area. (All passed.)
Please note that this is the nth instalment in my Java-on-the-Pocket PC series. You may want to read the following previous instalments; just to name a few (it’s the best to make a generic search on ‘Java’ on my nick in Pocket PC forums):
Compiling/editing Java on the PPC (http://www.pocketpcthoughts.com/index.php?action=expand,40880)
Create your own custom word dictionary - a working, free solution (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41049)
Using Java on the Pocket PC - the complete tutorial (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41081)
Now, for the tests:
NetFront 3.2 (http://nfppc.access.co.jp/english/):
It displays the applet, everything works (to a certain degree), BUT:
on VGA devices, in the standard, default SE VGA mode, and even in forced VGA mode, it uses low resolution in the applet area:
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJava.gif
Default SE
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJavaForcedVGAChopped.gif
Default SE, with forced VGA mode
As you can see, NetFront 3.2 miserably failed at the forced VGA mode: it just chops off half of the applet area. Therefore, never use NetFront in the forced VGA mode to render large applets!
In native VGA mode (the one that can be switched to with SE_VGA or OzVGA), everything worked just fine:
http://www.winmobiletech.com/072005RadarJavaTest/NF32NOAARadarJavaNativeVGA.gif
I’ve also faced another problem (which was the same with version 3.1 of Netfront, which had a completely different JVM): the memory and the CPU leak. Even horizontal scrolling of the applet are was almost impossible while displaying it, due to he memory leaks and the CPU usage; after exiting NetFront, the JVM still remained in the memory, totally slowing down the entire device. That is, if you use the JVM in NetFront 3.2, you most probably end up reseting your PDA after your Java session. This problem is particularly prevalent in native VGA mode.
I’m not very happy to say that the JVM in NetFront is still buggy…
Pocket Internet Explorer with the CrEme 4.00b8 (http://www.nsicom.com/Default.aspx?tabid=159) PIE plug-in:
It’s working great! Much better than Netfront 3.2 because
1, it’s Hi-res even in SE on VGA devices
2, is completely removed from the main memory after you exit, unlike the NF3.2 JVM.
http://www.winmobiletech.com/072005RadarJavaTest/Creme400NOAARadarJava.gif
A bit of warning: CrEme 4 blindly overwrites (instead of appending to it!) [HKEY_LOCAL_MACHINE\Loader], so, your all previous so-called “System path” settings will be gone! Please see for example this thread (http://discussion.brighthand.com/showthread.php?s=&postid=773927) on the System path and its usage. Also, as with the older (3.26) version, the installer EXE file won’t be able to execute on desktop Windows computers that have localized \Program Files directories (for example, \Programme with German Windows).
Thunderhawk 2.1 (http://www.bitstream.com/wireless/products/pocketpc/index.html):
Well, unfortunately, the c/s communication and plain image reload model of the TH JVM certainly sucks at both animation, bandwidth usage and, certainly, GUI control, as I’ve predicted here (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=40983) and, later, in my first “real” TH 2.1 test, confirmed here (http://www.pocketpcthoughts.com/forums/viewtopic.php?p=352806). While the “Set Animation Speed” slider can be dragged without problems in other browser + JVM combos, in TH, as you may already have guessed, it’s impossible to do this. Why? Because you only get an image, and not real, client-side GUI controls. This means you can only slide a slider one step at a time, in a very time (and bandwidth-) consuming manner. There is no way of dragging sliders at all!
Furthermore, it’s QVGA on VGA devices, and, what is more, the picture is skweezed – that is, you will hardly be able to make out what is written on the map:
http://www.winmobiletech.com/072005RadarJavaTest/TH21NOAARadarJava.gif
A quick TH tip never published before: the app creates a \Windows\winsys.bat file to store user information. If you remove/relocate it, you’ll be able to log into Thunderhawk from another user account – it’ll start with defining the new screen again.