<AWT Dev> <Swing Dev> Project proposal: fbtoolkit

[Stuart McCulloch]

On 25/05/07, Oleg Sukhodolsky <Oleg.Sukhodolsky at sun.com> wrote:
> imho all functionality suggested could be achieved by fb-based XServer,
> why do you need to reinvent the wheel and develop a toolkit which will
> implement some functionality of XServer, some functionality of Window
> Manager, and AWT toolkit.
>
> What is the advantage of the approach you suggest?

perhaps better use of memory/resources?

sometimes a bit of (re)invention can uncover new and interesting paths...

On 24/05/07, Phil Race <Phil.Race at sun.com> wrote:
> I don't think we have a clue what sponsorship means.  It certainly can't
> mean in  this case any work from Sun engineers ( wish we had time for
> such ideas ourselves), or taking it back into openjdk in any time in the
> forseeable future.

I guess the question I have about this discussion is whether openjdk
is just a place to grab the JDK source, or whether it's a place where
people can really take part, innovate and contribute back?

>
> Thanks, Oleg.
>
> Steph Meslin-Weber wrote:
> > Hi Phil,
> >
> > 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
> > usecases.
> >
> > 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
> > most appropriate.
> >
> > 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 [1]. 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
> > needed:
> >
> > "This example implementation will prefer pure-Java solutions, with
> > public extension points available to enter native resources as
> > necessary."
> >
> > 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
> > planned for.
> >
> >
> > 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.
> >
> > Example usecases:
> >
> > 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 [2]) 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
> >   router.
> >
> > 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.
> >
> > Thanks,
> > Steph
> >
> > [1] awtswing, http://kennke.org/~roman/swing-based-awt.png
> > [2] N800, http://www.nseries.com/n800
> > [3] Maemo, http://maemo.org/
> >
>

-- 
Cheers, Stuart  (whose all for open participation)