[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] <Swing Dev> Project proposal: fbtoolkit
From:       steph () tangency ! co ! uk (Steph Meslin-Weber)
Date:       2007-05-24 15:38:57
Message-ID: b6ce52930705240838t4f32742fw5bd873f32d3da7c3 () mail ! gmail ! com
[Download RAW message or body]

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/

-- 
================================================================
Steph Meslin-Weber,    steph at tangency.co.uk
================================================================


[prev in list] [next in list] [prev in thread] [next in thread]