>
> However, I also encountered some issues, affecting particularly MacOSX.
> Since Processing's renderer is fairly large, I created a small
> self-contained demo application that reproduces the issues I see in
> Processing, and also mirrors the basic structure of the Processing renderer.
>
> The code of the application is here: http://pastebin.com/H4pb3kik
>
> It is organized as an Applet contained inside a Frame, and uses a custom
> animator to render frames on demand. The GLWindow and NewtCanvasAWT canvas
> are created in a setup method that allows to hook the canvas either to the
> root frame or the applet object. I'm testing these two alternatives because
> each one has different issues and I haven't managed yet to get an
> initialization procedure that works 100%. So the issues are the following
> (on MacOSX Snow Leopard and Lion, behavior on Windows and Linux is slightly
> different but let's focus on Mac for the time being):
>
> 1) Hooking the canvas to the frame:
> frame.add(canvas, frame.getComponentCount() - 1);
>
> * window looses decorations on OSX
> * is not logically consistent: frame contains both applet and canvas as
> child components, but it should be frame -> applet -> canvas, shouldn't it?
>
> 2) Hooking the canvas to the applet:
> applet.add(canvas, this.getComponentCount() - 1);
>
> * target framerate (120 in the posted code) is not honored
> * gives invalid drawable error one time at the beginning

>
> I'm running all my tests with a recent autobuild package of jogl (post rc5).
> I'm also testing event handling, and have some questions about it as well,
> but will leave them for later.
>
> So my basic question at this point is: what would be the correct setup
> procedure for NEWT that works within this framework (Frame->Applet)? Since
> Processing's Applet class is basically a heavyweight AWT component, I'm
> wondering if issue-free integration of NEWT is possible at all. Maybe we
> need to stick with AWT's GLCanvas? Please let me know your thoughts,
> comments, etc.