XAWT: First useable (visible) results...

Scott Gilbertson scottg@mantatest.com
Wed Aug 27 15:41:00 GMT 2003


Per Bothner> Whatever overhead might be caused by using Gtk instead of Xlib
Per Bothner> directly is uninteresting on modern PC-class machines.

Right.  Best for embedded systems (like my app).  In my case, I don't care
whether the "normal" widgets (combo box, text area, etc.) are implemented,
because I use nothing but custom lightweight Components (apart from the
Frame, which is heavyweight).  I also have no interest in "looking native",
because my app is a test instrument with a non-PC-like user interface
(softkeys, numeric pad, rotary knob).  For this use I think gcj's xlib peers
are best even as currently implemented (unless you need certain things like
GIF/JPG loading, and I may have to fix that soon), mainly because of the
reduced static executable size and resulting faster load time from slow
storage.  Other developers of embedded systems may have requirements similar
to mine.  I would encourage them to use the xlib peers, warts and all, and
of course implement whatever parts they need that aren't working ;-)

Per Bothner> In fact, it is quite possible that using Gtk will be faster,
even
Per Bothner> ignoring issues of whether Java is as fast as C, just because
more
Per Bothner> people are working on Gtk performance than are likely to work
on
Per Bothner> AWT-for-GCJ-on-Xlib performance.

Just me and a couple of others at the moment working part time on gcj's xlib
peers, I think.  Performance has certainly been a key concern in my work
(example: font cache).

Per Bothner> The value of AWT-for-GCJ-on-Xlib is for limited-memory
limited-CPU
Per Bothner> devices, but for a GNU/Linux desktop running Gnome on a modern
Per Bothner> PC-class machine I believe AWT-on-Gtk would be better.  If
nothing
Per Bothner> else, it's more mature.

I'll second all of that.





More information about the Java mailing list