[ggo-discussion] Re: sgf editor sometimes crashes... at least when editing from game in progress.

On Fri, Dec 13, 2002 at 03:05:45AM -0000, Michael Camacho wrote:

> java.lang.OutOfMemoryError

Urgh. Bad.

> java.lang.OutOfMemoryError
> java.lang.OutOfMemoryError
> java.lang.OutOfMemoryError

Worse.

> java.lang.NullPointerException
>  at sun.java2d.pipe.DrawImage.copyImage(Unknown Source)
>  at sun.java2d.pipe.DrawImage.copyImage(Unknown Source)

Aha. That is from the rescale call of the kaya board image. I had this
before on Java 1.3 running on Mac OS X. But actually the Mac Java error
started somewhere inside the apple-own classes, while yours occurs in native
Java Swing code.

Some background info: Java offers a couple of methods to resize an image.
There are older methods in the AWT package that are quite fast, cheap and
have a bad result. A newer way allows a most excellent and smooth image
scaling, but is pretty costly in memory and CPU performance. However, when I
use the old, faster method, the Kaya board background has significant
artifacts and looks pretty ugly. The image is quite big, and I do not use
image tiling for the background but rescale the whole image to the complete
board size. I run a very poor box (PII with 128 MB RAM), but the rescaling
works quite okay for me, and this computer is really a low-end machine.
Michael, how much RAM does your machine have? I think my 128 MB are pretty
much the lower border for running gGo properly on Win2k, although it works 
quite okay
with this. On Linux 64 MB might still work, but considering Win2k alone
takes up ~60 MB space for itself, anything below 128 MB might cause
problems.

An idea might be to force a larger heap size for the Java VM by starting gGo
from a DOS line with the -Xmx128m argument, which would force a heap size of
128 MB (defaults to 64 MB): java -Xmx128m -jar gGo.jar
However, gGo hardly uses more than 64 MB RAM, the memory footprint is pretty
low, unless you load Kogo. Then it grows crazy.

Well, I am not willing to give up the high quality image resize code,
however if the problem is somewhat persistant (it was only reported twice to
me so far), I might add some checkbox "User faster but ugly rescale" or
whatever. Tho the kaya board looks *really* ugly with the old resize code.
Tiling is also no option, doesn't work well with this kaya image (see latest
qGo 0.0.13 release, which has a tiled kaya board.)

Basic information in those cases provided to me should include:
* gGo version
* Java version
* Operating system

Since 0.3.1 logfiles start with a line: "gGo 0.3.1 running on Java 1.4.1_01
(Sun Microsystems Inc.)", that is what I want to know. Additionally "Windows
2000" or whatever.

Just as some general remarks to the mailing list, what I consider useful
when doing bugreports. Michael knows this and doesnt send me his
configuration everytime he writes me a bugreport. He wrote me that many
times before. :)

It is occasionally surprising to see how much Java behaviour differs on the
possible permutations of Java 1.3.X, 1.4.X, the various windozes, Linux and
OS X. So far to "Write once, run anywhere", which is quite a joke.
Meanwhile I saw that gGo on Java 1.3 on Win9x basically just does not work.
<rant>Well, does anything work on Win9x except DirectX games? </rant>
Nevertheless, I like Java a lot and it basically offers an excellent
resources for multi-platform development, which has been on my top priority
list since I started qGo in C++ based on Qt, as I simply do not want to
create Yet-Another-Windows-Program.

Sorry for the long ranting. :)

 Peter

Other related posts: