Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Minimum Browser/System Requirements

2005-01-21
2012-11-08
  • Original message and reply reproduced below:

    -----------------------------------------------

    Hello folks,

    We have dipped our toe into the JavaDjvu water and encountered a "unexpected fault in IE" etc, etc, etc... The details mention a fault in "JIT.DLL". This is on a Win98 platform running IE 5.0 .

    I have no idea whether it is JVM 1.1 compliant or not and the MS support page ( http://support.microsoft.com/kb/155163 ) suggests disabling the internal JAVA JIT Compiler. I will have to go back to the offsite system to test that.

    Is there a minimum IE level, this support page indicates JIT exists back to IE 1.0, which JavaDjvu has to have in order to run?

    I would have posed this inquiry in the JavaDjvu Forums but they are closed ( you have to have a sourceforge sign-in ) to the masses.

    Senior Citizen

    -----------------------------------------------

    Sorry about that. I opened the JavaDjVu forumns to allow anonymous posts.

    Java DjVu has only been tested with IE 6.0. The minimum Java version tested with is Microsoft VM build 3805. Installing Windows service packs uninstalls the microsoft VM. This is the only version I could find for download. http://www.itnet.org/ms/msjavax86.exe .

    However, I if you are going to download an updated version of Java, then I recommend installing the Sun Java 1.5.0. This gives you optimal performance.

    However, if you are using an older machine it is more likely there error is due to memory. The minimum amount of ram recommended for a desktop size display is 96MB. (32MB's for your operating system etc. and 64MB's for the Java Virtual Machine.) I have not done mimimum configuration tests to find out how little memory you can have before you start to see errors as a result.

    Based on current security alerts, I would strongly recommend connecting a machine running IE 5.0 to the internet. The average time it takes to be infected with a virus after connecting the internet is just under two hours. This is the primary reason I don't test the applet with some of the older machines I have available.

    Bill

     
    • We went back and checked on the WIN98 - IE 5.0 system and found 128MB RAM. We didn't change the JIT setting because it isn't ours to modify. We did attempt a different smaller document but it still failed with the JIT.DLL fault.

      This is exactly why I went to an outside location.

      If I am to adopt JAVADjVU for my website, I have no control over who will visit the website and attempt to use the JAVADjVU Viewer. Currently, they have no idea whether their combination of OS, Browser, JAVA version and hardware requirements permit them to view the archives.

      With the multitude of various combinations, experience and knowledge of upgrading, and authority to modify or authorize downloading, installing, adding hardware, etc..., it doesn't make sense to create code which requires the latest version of "xyz" in order to work.

      Just because you or I might not normally run older stuff on the net due to malicious and nefarious things, doesn't mean that "BOZO the newbie" or "PEON behind the corporate/institutional firewalls" isn't still slugging away with old equipment and software.

      Now, with that out of the way.

      What does work:

      IE 5.0 under WIN2K with 256MB RAM
      IE 5.5 under WIN2K with 256MB RAM

      Firefox 1.0 under WIN2k had one glitch; you need plugin; install plugin by clicking here; downloading, installing; downloading (20 minutes or so on dialup), JS2E Runtime Environment 5.0, message to restart Firefox for plugin to work; recieved popup window about default profile (in use); created new profile (JAVA); JAVADjVu Viewer works.

      Senior Citizen

       
    • I agree, it would be nice for the applet to run with the minimum requirements possible. I have some ideas for the roadmap that would help reduce the memory requirements further. But in response to the JIT.dll bug, I can not tell you the cause, I can only guess. Without the opportunity to actually debug on a platform or collect meaningfull log files, guessing is my only diagnostic tool. I can say, that no matter what my java code is, it should not create this error. So ultimately the problem is a bug in JIT.dll, but it may be agrivated by something in the code. On the versions of the microsoft virtual machine I was able to debug and test with I found and fixed many such problems. But it is not surprising even older versions of the dll have even more bugs to work around.

      Unless someone sponsors a significant amount of development time and hardware dedicate to resolve these issues, my suggestion is if the microsoft virtual machine has these problems upgrade to the sun version of java. Not only should that fix the problems, but Java 1.5.0 runs significantly faster than previous versions of java.

      Bill

       
    • I looked around on the net and found other applications having problems with JIT.DLL as well. The finger pointed to IE, not JAVA code. A MS page may detail the offending versions of IE:

      http://support.microsoft.com/default.aspx?scid=kb;en-us;155163#kb3

      I installed WIN98 Second Edition on an old IBM Thinkpad 120Mhz Pentium, 48MB RAM. The same JIT.DLL error was present. Turning off the JIT compiler permitted JAVADjVu Viewer to work correctly (slowly).

      MS site lists several versions (builds of IE), we only tested 5.00.2614.3500 IE 5 released as part of WIN98 Second Edition and 5.00.2920.0000 IE 5.01 released as part of WIN2K 2000.

      What does not work:

      IE 5.0 (5.00.2614.3500) under WIN98se if JIT.DLL compiler option is checked.

      IE 3.0 under WIN95. (unable to load/find class etc... in status bar). Didn't expect it to work but it was on the laptop initially.

      What does work:

      IE 5.0 (5.00.2614.3500) under WIN98se if JIT.DLL compiler option is not checked (48MB platform).

      IE 5.01 (5.00.2920.0000) under WIN2K
      IE 5.5 sp2 (5.50.4807.2300) under WIN2K

      FireFox 1.0 under WIN2K using Java Version 1.5.0

      The JAVA plugin install has ursurped the IE java runtime environment. This has caused another test for performance. All tests were run offline on the same platform 500Mhz AMD K6-2 256MB (dual boot - WIN2K, 1 MS JIT, 1 Sun Java). Time is from clicking on HTML file with JAVADjVu document embeded to display of DjVu document.

      Using IE 5.01 (original MS JIT) - 8 seconds

      Using IE 5.5 (JAVA 1.5.0) - 2 minutes 41 seconds

      Using FireFox 1.0 (JAVA 1.5.0) - 2 minutes 38 seconds

      The test was run on a couple of other systems as well. From the results, it appears something is going on before execution ( 8 seconds vs more than 2 minutes). Any ideas, suggestions?

      Senior Citizen

       
    • > I looked around on the net and found other applications having problems with JIT.DLL as well. The finger pointed to IE, not JAVA code. A MS page may detail the offending versions of IE:

      Yes. As I said previously, the bugs are caused by JIT.DLL, but aggrivated by the code. As an example, often times initializing a static value with a conditional statement will cause a JIT.DLL fault. i.e.

      static String foo=bar?"true":"false";

      In some versions of the microsoft virtual machine.

      I find your tests with Java 1.5.0 interesting. I've never seen it take more than 12 seconds to load anything, except on my PDA. So definitely something usual is happening. Perhaps your webserver is stalling? Make sure you are not trying to view an item in IE cache, as it would give the Microsoft Virtual Machine an unfair advantage in your test.

      Bill

       
    • All the tests were conducted off-line from local directory.

      Test environment:

      Class and JAR file from 0.8 build.zip file SourceForge.
      HTML document ( reproduced at bottom of this post )
      DjVu document

      IE 5.5 started with blank page, then C:\atest\javatest.html to start testing.
      HTML page has a small JAVAScript to display timestamp on page.
      Refresh button depressed upon appearance of loaded DjVu document gives new timestamp.
      Difference is reported as time lapse in tests below.

      I just completed three tests:

      1st with a ANY2DJVU converted from PDF B&W 400 DPI.

      initial appearance of DjVu document - 1 minute 36 seconds
      2nd appearance when refreshed - 24 seconds
      3rd appearance when refreshed - 17 seconds

      2nd with a DjVulibre converted from TIF B&W 600 DPI.

      initial appearance of DjVu document - 1 minute 02 seconds
      2nd appearance when refreshed - 21 seconds
      3rd appearance when refreshed - 19 seconds

      3rd with a DjVulibre converted JPG color 600 DPI.

      initial appearance of DjVu document - 10 minutes 12 seconds
      2nd appearance when refreshed - 8 minutes 39 seconds
      3rd appearance when refreshed - 9 minutes 32 seconds

      It took almost 5 minutes for the Sun Java to disappear and the Java DjVu Viewer toolbar to appear in this last group.

      I captured the JAVA console data for these last three as well, see below

      Java Plug-in 1.5.0
      Using JRE version 1.5.0 Java HotSpot(TM) Client VM

      Trying file:/C:/atest/ostestsmall.djvu
      1. chkid=Sjbz,used=27526384 time=1106707647
      1. chkid=FGbz,used=28041792 time=1106707650
      1. chkid=BG44,used=26907968 time=1106707652
      1. chkid=Sjbz,used=28073240 time=1106707663
      1. chkid=FGbz,used=28661368 time=1106707664
      1. chkid=BG44,used=29114064 time=1106707664

      Trying file:/C:/atest/ostestsmall.djvu
      1. chkid=Sjbz,used=58875592 time=1106708221
      1. chkid=FGbz,used=60733608 time=1106708223
      1. chkid=BG44,used=56276896 time=1106708223

      Trying file:/C:/atest/ostestsmall.djvu
      1. chkid=Sjbz,used=57730656 time=1106708832
      1. chkid=FGbz,used=60315608 time=1106708834
      1. chkid=BG44,used=55879360 time=1106708835

      <html>
      <head>
      <title>Example</title>
      </head>
      <body bgcolor="#ffffff" leftMargin="0" topMargin="0">

      <SCRIPT LANGUAGE="JavaScript"><!--
      // This script will retrieve and display the current time.
      // Author: M. Doucet
      Stamp = new Date();
      var thishour = Stamp.getHours()
      var thismin = Stamp.getMinutes()
      var thissec = Stamp.getSeconds()
      if (thishour < 13){
      var meridiem = "AM"
      var acthour = thishour
      }
      else{
      var meridiem = "PM"
      var acthour = thishour - 12
      }
      if (thismin < 10){
      var actmin = "0" + thismin
      }
      else{
      var actmin = thismin
      }
      if (thissec < 10){
      var actsec = "0" + thissec
      }
      else{
      var actsec = thissec
      }
      document.write(acthour + ":" + actmin + ":" + actsec + "<FONT SIZE=1> - " + meridiem + "</FONT>")
      // --></SCRIPT>

      <applet
      code="DjVuApplet.class"
      archive="javadjvu.jar"
      width="640"
      height="480" >
      <param name="data" value="ostestsmall.djvu">
      </applet>
      <a href="About.html">next test
      </a>
      </body>
      </html>

      Senior Citizen

       
      • Hmmm. For comparison try Java 1.4 or Java 1.3 on the same machine. The times displayed in the console are showing how long it takes to decode the DjVu files. The first instance shows two sets of decoding, because the icons for the toolbar are also in DjVu. In the latter instances, the icons were already decoded and cached in memory.

        Typically, the time between decoding the toolbar icons and the decoding the document should represent the IO time it takes to transfer the the file across the network. Since you are loading from local disk, the time should neglishable. But even that took 11 seconds.

        Did you run these tests on the machine with 48MB's of memory? If so that is your problem. In the third test, the applet is using 56MB's of memory for decoding the 600 DPI photo. Chances are your system is already using most of your memory for other tasks. Consiquently, almost none of the time is spent running the java applet, most of the time is spent page swapping to disk.

        Does your task manager performance tab show a significant amount of paging activity?

        I would definitely say given your results, Java 1.5.0 is not the answer for this particular setup. I believe even sun recommends at least 64MB's memory for a light weight java applet, like "hello world". My own recommendation is at least 96MB's memory for viewing typical 300 DPI letter sized documents. It is interesting to hear the Microsoft Virtual Machine does better in low memory configurations.

        Bill

         
    • I just read your other message more carefully and saw:

      All tests were run offline on the same platform 500Mhz AMD K6-2 256MB (dual boot - WIN2K, 1 MS JIT, 1 Sun Java).

      Unless all your memory is in use, there is no reason why should be experiencing a large amount of paging activity.
      So if it turns out that isn't the problem, the question is what is the problem. The CPU speed is about the same as my Mac, so that shouldn't be the problem.
      That would leave temporary code deadlock, IE version, disk configuration, or an actual flaw in the java 1.5.0 plugin. I assume you aren't doing something silly, like installing java directly onto a zip disk or such. So the next thing to try would be a different version of the java plugin.

      Bill

       
    • Further testing:

      Removed Sun JAVA 1.5.0:

      test with IE JIT
      3 minutes 31 seconds
      3 minutes 24 seconds
      3 minutes 24 seconds

      test with IE JIT window reduced to 100 x 100
      43 seconds
      38 seconds
      38 seconds

      installed Sun Java 1.3.1

      test with 1.3.1
      5 minutes 14 seconds
      5 minutes
      5 minutes 2 seconds

      test with 1.3.1 window reduced to 100 x 100
      1 minute 5 seconds
      1 minute 1 second
      1 minute

      So reverting to older version of JAVA reduces time somewhat, but nothing near 12 seconds.

      I was going to package the source JPG and the DjVu file used in the test and noticed the DjVu file was over twice as big as the original JPG. Checking the properties of the JPG with IMAGING, I find it was not 600 DPI after all, but 24 bit color at 300 DPI 1.99" x 1.5" with medium JPG compression 55kb in size. The DjVu file used in the test has page information of 596x450 100 DPI 0.0 kb INFO 110.6 kb Sjbz 10.6 kb FGbz 256 colors 11325 ccs 0.0 kb BG44 Compression ratio 7 (121.2 kb).

      Since the DPI between the two are different, I currently don't remember how I created the DjVu file.

      I created a new one with

      c44 -dpi 300 ostestsmall.jpg ostestnew.djvu

      and low and behold we now test at

      initial load 14 seconds
      2nd refresh 8 seconds
      3rd refresh 8 seconds

      The original test document opened with a small fraction of the whole document in the viewer, while the recent test document opens with a small image of the whold document in the viewer.

      JPG, old and new DjVu test documents are zipped and available for further examination at www.softlib.org/test.zip 231 kb

      This JPG is not the original source for all this stuff, just an attempt to get something smaller to work with than the original 96 MB TIF, so who knows how I would up with a file which gives something a case of the slows.

      Senior Citizen