<AWT Dev> Ideas about improved architecture of the generic Swing peers

[Roman Kennke]

Hi Artem,

> I haven't had a chance to look at Caciocavallo project, so some of my 
> questions may look pretty naive, but still:
> 
> 1. Do I understand correctly, that you're using XToolkit approach: each 
> component has its own native (heavyweight) window, but all the drawing 
> is performed in a lightweight manner?

Yes.

> 2. A small note about original email. Most of the problems described in 
> the email are related to a known AWT limitation about using both heavy- 
> and lightweight components inside a single container. As of JDK7 this 
> limitation is eliminated, and hw/lw mixing works pretty well and fast.

Cool. But we don't really mix LW and HW.

> 3. What is PlatformWindow interface? Does it correspond to a top-level 
> window or any heavyweight component?

This corresponds to each HW component, because all components use a
native window. The interface is similar to WindowPeer plus
ComponentPeer, but with some quirks. For example, in the XToolkit, you
have the XComponentPeer which is a subclass of XWindow. XWindow
implements all (most?) of the actual window functionality. What we are
doing is similar, but IMO more portable: CacioComponentPeer implements
all the window functionality, but by delegating the platform dependent
parts to an implementation of the PlatformWindow interface. The
PlatformWindow implementation is responsible for handling the window
(e.g. setVisible()) and for passing back events from the window system
to the CacioComponentPeer (which in turn passen the events on to the
EQ).

> 4. Do you suggest an approach when a lightweight (Swing) component is 
> inserted into an AWT widget (aggregation) or just reuse some painting 
> and other Swing stuff (draw Swing components onto AWT components)?

I don't insert Swing into AWT. From the POV of the application, it
should never see the Swing components used. The peer instantiates the
Swing components, but does not add it to the AWT hierarchy. But it does
some tricks, so that the Swing components 'thinks' it has a valid
parent, to allow painting and some other stuff.

> 5. You write your current implementation works on X11 with EscherToolkit 
> on top of it. Do you think it would be hard to use existing AWT 
> toolkits: XToolkit & WToolkit - for an underlying layer?

I'm not sure what you mean by that. I think it should be possible to use
X11 or Win32 for underlying layer (Escher == X11/Xlib in 100% Java). If
you want to use the Swing peers in XToolkit or WToolkit, you'd have to
implement the PlatformWindow interface in these toolkits and subclass
from CacioToolkit, instead of SunToolkit.

/Roman

> 
> Thanks,
> 
> Artem
> 
> Roman Kennke wrote:
> > Hi folks,
> > 
> > I'm CCing awt-dev now, I think this could be interesting. Please scroll
> > down and read the original mail so that you know what I'm talking about.
> > Basically, I'm trying to implement AWT peers that are based on Swing
> > (for the widgets) and require minimum effort for porting to new
> > platforms. Basically, the only thing that is required to be implemented
> > on a new platform is the windowing functionality, abstracted out nicely
> > by the PlatformWindow interface.
> > 
> > Today I pushed a first prototype of the new Swing based AWT peers. It
> > follows the basic architecture described in the original email (all
> > components have their own native window, which is abstracted behind an
> > interface, components are backed by their Swing counterparts for drawing
> > and state handling). So far, this only serves as proof-of-concept. It is
> > possible to open a Frame and put Canvas inside it. The code is based on
> > the patches of the Caciocavallo project (which should probably be merged
> > in mainline at some point). You can find the code here:
> > 
> > http://hg.openjdk.java.net/caciocavallo/ng/
> > 
> > The basic framework is located in the package sun.awt.peer.cacio, an
> > example implementation based on Escher [1] can be found in
> > gnu.java.awt.peer.x (start looking at EscherToolkit maybe).
> > 
> > and the patched OpenJDK forest here:
> > 
> > http://hg.openjdk.java.net/caciocavallo/jdk7/
> > 
> > 
> > Questions, suggestions, comments and code are heartily welcome :-)
> > 
> > Cheers, Roman
> > 
> > [1] http://escher.sf.net
> > 
> > Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
> >> Hello people,
> >>
> >> I'd like to outline my ideas about an improved architecture of the
> >> generic Swing based peers. But let me first describe the current state
> >> and the problem(s) we need to address:
> >>
> >> Currently, the Swing peers implement most of the peers in
> >> java.awt.peer.* (well ok, minus a couple of complex ones, like
> >> ScrollPane, Choice, etc). They are not supposed to work standalone, but
> >> need some support by a real backend. Most notably, this would be an
> >> implementation of java.awt.Toolkit and the top-level window peers
> >> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
> >> the Swing peers handle all the widgets in a semi-lightweight fashion:
> >> all the drawing is done using Graphics contexts from the toplevel
> >> windows. However, the actual Swing components are not connected to the
> >> component hierarchy in any way, they are only 'hooked in' in a way, so
> >> that from the perspective of the Swing component it appears as if it
> >> were in the component hierarchy, but infact it isn't (from the
> >> perspective of the hierarchy).
> >>
> >> This architecture, requiring the real backend to implement the toplevel
> >> windows, and do everything else in a quasi-lightweight fashion has some
> >> disadvantages, or at least, one big disadvantage. It is really hard to
> >> get the special behaviour of AWT heavyweight components correct. For
> >> example, suppose you have a Frame, inside this frame you have a Swing
> >> component, and a Panel. The panel would always be on top of the Swing
> >> component, regardless of the stacking order in the window. To make it
> >> even more complex, if you had a Swing component in the Panel, it would
> >> be drawn on the Panel, not on the Window (an thus, it would appear to be
> >> always on top of the other Swing component). To get this right in the
> >> Swing peers, we had to implement a bunch of hacks, that involve double
> >> buffers for all components and other ugly stuff, and it never worked
> >> really well.
> >>
> >> The answer, for me, was found in the implementation of the XWindow peers
> >> in OpenJDK. All AWT components are 'simply' given their own X Windows.
> >> I, coming from a Swing background, first had to get over this concept a
> >> little, but then it seemed all logical, and I think most toolkits (at
> >> least in the X world) are implemented like that. And even though not
> >> specified exactly, Java AWT applications expect such behavior from AWT
> >> components.
> >>
> >> What I would like to propose is a kind of blend between the architecture
> >> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
> >> be drawn in their own window, but let Swing do the drawing and handling
> >> of logic and events. This way, we would get a maximum portable AWT peer
> >> implementation, that requires only minimal effort to port to any new
> >> platform. The interesting part is to implement this idea:
> >>
> >> The first thing to think about is that all components should have their
> >> own window. To me, this means, that the common superclass of all the
> >> peers, the SwingComponentPeer, must implement all the necessary
> >> windowing behaviour. This is done similarily in the XAWT peers, but in a
> >> very X specific way. All other peers, including the toplevel peers and
> >> the widgets, derive from this class (an exception would probably be the
> >> menu related peers). Since SwingComponentPeer already implements all the
> >> necessary windowing functionality, the toplevel peers don't have much to
> >> do on their own, except delegating to super here and there. The widget
> >> peers now don't search for a parent graphics for drawing, but can do
> >> everything in their own window.
> >>
> >> The tricky part here is, when the SwingComponentPeer is at the top of
> >> the hierarchy, how can we 'plug in' platform specific code there?
> >> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
> >> interface, which is used by the SwingComponentPeer to delegate all the
> >> real window implementation stuff to. We should be careful to create a
> >> nice clean interface there. Porting the AWT would then be as simple as
> >> implementing this one interface (plus J2D pipeline), and boing! have all
> >> the AWT widgets and toplevel windows available.
> >>
> >> And we need to consider that not only SwingComponentPeer calls into the
> >> PlatformWindow impl, but the PlatformWindow impl also needs to call back
> >> to the SwingComponentPeer for handling events. In the XAWT
> >> implementation this is done by passing back X events. Of course, we
> >> don't want platform specific events in the Swing peers. So the
> >> PlatformWindow implementation needs to take care and transform all
> >> platform specific events to Java AWT events before passing them back to
> >> the SwingComponentPeer. It might be necessary to introduce a couple of
> >> internal peer events for handling stuff that is not covered by the
> >> 'official' AWT events.
> >>
> >> Summary of the architecture outline (this would be a good point to slip
> >> in an UML diagram, but I really don't like diagrams ;-) ):
> >>
> >> SwingComponentPeer is the all-mighty master superclass here. It provides
> >> all the necessary windowing functionality. But it doesn't implement this
> >> itself, but instead delegates to a PlatformWindow implementation.
> >> PlatformWindow would be an interface that specifies all the windowing
> >> functionality that we need from the underlying platform. The
> >> PlatformWindow implementation is also expected to pass all the events
> >> from the window to the SwingComponentPeer, in the form of AWT event
> >> objects (it must already translate the native event types to the
> >> corresponding AWT events). Subclasses of SwingComponentPeer implement
> >> both the widgets as well as the toplevel windows. Drawing the widgets
> >> and handling the state logic of the component is done by Swing.
> >>
> >> Please tell me what you think.
> >>
> >> Cheers, Roman
> >>
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080904/cfde8264/attachment.bin