MacOSX plugin2 idea

[bobjob]

I have had success using Rococoa to access QTKit (webcam capture/video player) on my site, via a cocoa component. It renders well in Plugin 1 and 2.

I was thinking, is it worth attempting an OpenGL (CocoaComponent) canvas in Rococoa just for the bugs shown in Mac applets plugin1, and the silent error in plugin2?

Or will this just create the same error as the current implementation?

[kappa]

A native window implementation would be pretty cool for mac, would allow moving away from the current AWT window used there and be much more flexible and future proof.

Not sure Rococoa is the best way to go though, its GPL, so not sure if it'll go too well with the BSD licence and the library has other dependencies (JNA, ASM, etc). A thin JNI and Cocoa layer might be the way to go but if you can show Rococoa works might be incentive to get the JNI version done.

As for making plugin2 work, its worth a try but might require some ninja skills to get it working.

How LWJGL Applets work on windows and linux is that they get the native window and stick it on top of the applet AWT Canvas, this is done by grabbing the native window handle (HWND) of the awt canvas and setting setParent on LWJGL's native window. This allowed for fast and stable rendering separate from any AWT rendering thread. As LWJGL Mac windowing system used AWT using the same technique was not possible since its native setParent code isn't exposed, so it was just embedded normally through java. Worked well enough.

Now as far as I know the main issue with getting this technique working on plugin2 is sticking the native window on top of the AWT Canvas. If we can get this step working, the rest should all be possible and we'll have the fastest java applets around .

It would have been possible on mac's plugin1, but I fear that on java plugin2 there is no window handle (HWND) on the AWT Canvas since its all drawn to an offscreen buffer first and then to the browser with CoreGraphics.

If you do investigate this further, do keep us updated.

[bobjob]

Its very tedious to write out a whole library, and Im having some problems with the pre-generatated libraries not being dependant on JNAerator (I think the rococoa that Im using is old, another thing to fix).

So I figure that its not worth the effort, if the final implementation is going to be implemented using JNI anyway.

[kappa]

Oh and just for completion here is a response I got from an Apple Java Engineer regarding the plugin2 OpenGL situation (in bold).

Since the new updates to the plugin2 system ('Out of Process Applets'), almost all of the applets related to java gaming and libraries have suffered a massively drop in performance and OpenGL applets have been broken totally (both LWJGL and JOGL libraries).

OpenGL applets have started to become pretty popular of late, with many companies now starting to look at this tech, as its cross platform and allows powerful 3d games to run easily in the browser. Its working well on Windows, Linux and plugin1 Macs.

There was a mention in some of the release notes that JOGL/LWJGL may work in the near future but with recent announcements, its unlikely this fix will ever see the light of day now and could lead to this tech unavailable in the future, besides there would still be a performance penalty if it worked through the current plugin2 rendering implementation.

I was hoping to find a solution to allow LWJGL to work on macs with plugin2 and hope you people can help out a little or provide some solutions or understanding to the inner workings of how the rendering is done with plugin2.

As I understand it, all rendering is now done to an offscreen buffer and then drawn into the browser using CoreGraphics.

LWJGL has its own native window (not swing or awt) when run as a normal application, when its run as an applet it grabs the window handle (HWND) of an AWT Canvas on the applet and embeds itself on it using setParent(). This works really well on linux and windows. Does plugin2 on mac with CoreGraphics even have a hwnd? is it possible to embed a native window some other way on plugin2?

In the CoreGraphics drawing model, there may not actually be a window at all, since target of the drawing may be shared memory between the browser process and a plugin "shim" process (which then kicks off it's own JVM when using Plugin2). Cross process window sharing is not easy and does not provide a reliable user experience on Mac OS X, even when you have access to the private SPI in the system.

Further, is old non CoreGraphics renderer still available (maybe some sort of jvm parameter could be added to enable it) ? I noticed that if you turn off 'out of process applets' to switch back to plugin1 it works, so maybe there is some internal way to enable this to work with plugin2. Do note LWJGL uses signed applets, so native code can be used to solve this problem and there are no sandbox restrictions.

Hopefully a solution can be found for this issue.

Our long-term goal is to move Plugin2 onto a CoreAnimation-based graphics rendering system, which will allow us to share a CALayer between processes. Ideally, 3D libraries like JOGL or LWJGL will be able to attach a OpenGL-backed sublayer, which will be inherited in the cross-process render tree automatically. This however, is still a ways off, and will require a substantial amount of engineering.

For now, unfortunately, the only viable option is to use Plugin1 in browsers that support it.

I hope this explains some of the technical issues that have to be overcome,
Mike Swingler
Java Engineering
Apple Inc.

so a fix is unlikely to come anytime soon from apple.

[jediTofu]

Mac OS X having recently silently deprecated Java on the Mac OS X...this doesn't surprise me.