<AWT Dev> <Swing Dev> Project proposal: fbtoolkit
steph at tangency.co.uk
Thu May 24 08:38:57 PDT 2007
Thanks for your comments, I wasn't certain how verbose the initial
proposal was supposed to be so we left out the details from the
In order to keep this thread in one list (it's starting to confuse
Gmail a bit) we could continue this conversation in discuss for now.
I have Bcc'd the other lists (including 2d following Mark's use) to
let everyone on those lists know to check discuss for followups:
Bcc: awt-dev at openjdk.java.net
Bcc: 2d-dev at openjdk.java.net
Bcc: swing-dev at openjdk.java.net
As the discussion moves on we can move it to the one group that seems
On 23/05/07, Phil Race <Phil.Race at sun.com> wrote:
> I don't follow what this has to do with Swing. 2D would be more affected ..
> Swing is ignorant of whether the Motif or X toolkit is specified
> and even works with the headless toolkit.
Agreed, Swing shouldn't use knowledge of the underlying
implementation. The reasoning behind including Swing in the discussion
is the SwingAWT work by Roman Kennke. In his project, he implemented
AWT peers using Swing . Now, whether the Swing implementation is
native is another topic of discussion :-)
> Also the existing toolkits can still leverage all of the
> same internal 2D native code for rendering. I don't see where
> you are going to get that from unless if its going to be
> a pure Java solution.
I think here we tried to show that the example implementation would be
written in pure Java, with extension points to break to native code as
"This example implementation will prefer pure-Java solutions, with
public extension points available to enter native resources as
Starting with pure Java means we have a baseline that is easier to
understand than one that jumps back and forth to native code, this
also incidentally makes it an ideal example for those wishing to write
their own set of peers. It's a given that without those jumps certain
optimisations aren't practical to implement, but that's why we'd like
to do this in the open so those situations can be discussed and
Before going on to a few usecases, I'd like to mention that I already
have a fair amount of code in support of this proof of concept, including
providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!)
a pure Java X11 provider; there is also embryonic work on an SDL provider
to ensure we cover as many platforms as possible.
> > Examples of usage include: implementation debugging, device
> > emulation, multiple-head clone outputs/inputs, simultaneous
> > multiple-peer output, etc.
1) Implementation debugging is one that is fairly simple to explain,
it becomes a tool for us to track down AWT/Swing issues by excluding
native resources as a possible error source. (Yes it introduces
another factor, but at least it's independent). This also allows for
some device emulation, screen sizes, pixel encoding, etc.
2) Realtime output/input on a device (say an N800 ) with
simultaneous output/input of the exact same screen contents on an
attached PC. This is in effect multiplexing two different devices onto
a single Java stack. Control of the device from the PC. Useful when
your touchscreen driver isn't written yet.
3) Distributed remote software agents exposing a VNC or X11 capable
UI. Easier to secure and to use than a fullblown VNC or X11 server on
a dedicated host. Easier to deploy too. This is in effect a
kernel+jvm+libc on any hardware. Including headless ones like a
4) Point of Sale, The network is the machine, etc... lightweight PXE
images booting a rich Swing UI direct to their framebuffer. Small PXE
image, few external dependencies. For bonus points, let the client
decide which provider to load from a Jini cloud depending on need.
5) Multicast a single UI via VNC, kiosk-type advertising or
interaction: one window per terminal.
Please let me know if I've left a few out.
 awtswing, http://kennke.org/~roman/swing-based-awt.png
 N800, http://www.nseries.com/n800
 Maemo, http://maemo.org/
Steph Meslin-Weber, steph at tangency.co.uk
More information about the awt-dev