This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A little Swing challenge...


Hello all,

anybody got some free time over the weekend? I attach the source code
for a little Swing application that *almost* works with gcj. I only
had to uncomment a few calls to JTree/DefaultMutableTreeNode that are
still missing or are implemented as stubs only. At the same time, the
app might be a nice addition to your regular Swing tests and it might
even be useful in the near future (after fixing the perfomance issues).

Perhaps someone with a current GCJ installation and AWT/Swing knowledge
can unpack and compile the .tgz and tell me whether it works?

--- About the code ---

The application is a simple Swing-based image viewer, niffler.JImageViewer.
A webstart version is available at:
http://tams-www.informatik.uni-hamburg.de/personal/hendrich/niffler

When called with a directory name, a worker thread searches for all
image files (.gif, .jpg, .png) in that directory and its subdirectories.
The corresponding file tree is shown in a JTree and flattened into a
list for direct access via an index. You can then easily view single
images, navigate to the next, previous, random images, etc. or start
a slideshow. There are several options to control image size, too,
e.g. fit-to-window, fit-to-width, original-size, etc.

I use this application as a portable (Win/Linux) viewer for my digicam
images, as well as to browse through images downloaded from websites
(wget -r style) or to search for images that I managed to lose on my
filesystem. Using the bindkeys, I can use this much faster than any 
of the 'standard' viewers (like the WinXP builtin viewer or IrfanView).

When run in a recent JDK, performance should be adequate for images
up to 3000x2000 pixels. Above that, the JDK seems to get into trouble,
e.g. browsing through Dia-Scans at 6000x4000 is terribly slow. Using
javax.imageio instead of the handwritten calls to Toolkit.prepareImage
does not improve things. But perhaps a future version of GCJ will
solve performance issues for images that large?!

BTW, the name 'niffler' is taken from the Harry Potter books. 

--- GCJ ---

On my gcj (snapshot gcc-4.0-20050130) installation, the app compiles fine
after the five changes documented in JImageViewer.java. It starts fine, 
too. However:

* the popup-menus (especially the nested menus) show up on wrong positions
  (this may be WindowManager related, I use ctwm).

* popup->select directory brings up a JFileDialog that instantly dies.  
  
* the JTree shows the files of the toplevel directory (because I have to
  use rootNode.children() instead of rootNode.depthFirstEnumeration())
  but otherwise is dead  

* perhaps someone is interested to implement the stub methods in Default-
  MutableTreeNode like depthFirstEnumeration() and the required methods
  in JTree?

* loading images is *incredibly* slow. Note that loading the raw image
  data and actual image rendering is pretty fast, but the call to
  Toolkit.prepareImage() seems to have a problem. On my PC (Athlon 2600+),
  I get CPU times of 50+ seconds to load a single 800x600 JPEG...
  
* keyboard input does not work at all. Either the JImageCanvas doesn't get 
  the focus, of keyPressed()&Co are not implemented correctly.
  
* the JScrollPane mostly works, but sometimes does not react to changes
  of the image size. (However, the JDK JScrollPane still doesn't work
  correctly, either...) However, mouse dragging of the image works fine!

Please let me know if and how this works for you!  While the code probably
is not "FSF-quality", you may still use it as you like.

- Norman

Attachment: niffler-gcj.tgz
Description: niffler-gcj.tgz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]