Dalibor Topic wrote: > > --- Alexander Hvostov <[EMAIL PROTECTED]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dalibor Topic wrote: >> >> > In my opinion, a pure java, liberally licensed, free software, swing >> > implementation would be preferable to native-toolkit based swing >> > implementations. The hypothetical [1] native speed advantage is not as >> > important as cross-platform/cross-vm deplayability of Swing apps to me. >> >> Why does this preclude a native toolkit based Swing implementation, so long >> as it implements the spec properly? It would seem to me as that would >> simply make it faster when in use -- a scenario of having your cake and >> eating it too. > > Oh, it doesn't preclude it. I just think it's not as convenient as it sounds.
At issue is not convenience, but speed. Swing is horribly slow, so any effort to speed it up seems worthy to me. > A pure java implementation would be immediately useful for all the other free > JVMs out there which have a working AWT (wonka, kaffe, gcj(?)) on all platforms > without introducing another dependency on the toolkit used for the Swing > implementation. A pure java swing should run on an embedded system with an AWT > implementation over microwindows, as well as on a MS WinXYZ desktop with an MFC > based AWT implementation. And be slow as hell, just like Sun's. What do you gain? Having a pure Java Swing implementation to fall back on is a good idea IMO, but having a pure Java Swing implementation at the expense of a faster native implementation when the latter is available seems foolish. > <vaproware> > With gcj, you could be able to compile that awt ahead of time on any platform, > and eat your cake there, without yet another porting effort to yet another > graphics library. > </vaporware> Parse error: '</vaporware>' without open-tag. ;) Seriously, though, not really. Sun AWT consists of a great deal of native code, and is not at all slow. Sun Swing, however, is very slow. >> > [1] I'm not aware of anyone, commercial or free, who has managed to write >> a >> > Swing wrapper around a native graphical toolkit. So any claims of a speed >> > advantage by implementing Swing in native code are purely hypothetical. >> >> ISTR stumbling across a Swing implementation coded up in C++ on the GCJ >> mailing list archives. That doesn't make it a wrapper around another >> toolkit, but it does give you a speed improvement, as it should >> (theoretically) be almost as fast as GTK or Qt or the like. > > The only thing I found was a post by Troy Wu (CC:ed) > http://gcc.gnu.org/ml/java/2000-08/msg00002.html but no code. He claims a 5-10 > fold improvement in drawing parformance, but there is no code. He used Xlib in > his code, and that means it's not useful for legacy/restricted systems without > Xlib ... I don't think that's it. My recollection is vague, though. Alex.
