Integrating native Open GL code in JavaFX and alternatives

Artem Ananiev artem.ananiev at
Mon Jan 28 02:37:40 PST 2013

On 1/26/2013 7:00 PM, David Hill wrote:
>> 1. If a native Window/Scene handle is provided, it will be enough to
>> embed whatever you need. It will even be possible to embed D3D content
>> into JavaFX running with OpenGL pipeline :)
>> The question is what is the native handle? On Windows, HWND is the
>> answer. On Mac: NSView or CALayer? In the latter case we'll also need
>> mechanism to flush embedded layer content into the parent (window)
>> layer, and the thing will get complicated.
> I think you need a bit more than just a handle.
> Given the problems that I am deep into correcting now, there seems to be
> a strong requirement to single thread not only the rendering, but (at
> least on some platforms) the window manager interaction. Given that JFX
> uses an inherently multi-threaded approach, (rendering is largely done
> off of the user event thread, but events and rendering triggers are on
> the user thread), there needs to be some mechanism that would allow this
> entity with the native handle to play nicely. This would mean either
> exposing some of our current locks, or more likely telling the users
> "canvas" node that it is its turn to paint.

Public locks imply multi-threaded rendering, which we all would like to 
avoid. Telling user nodes that it's time to render sounds more 
reasonable to me, but it's less predictable from application's point of 



> The problem I am working on now revolves mostly around window state
> changing while we are (or are about to) render.
> For the GL case - I think we would also need to hand over a known state
> GL context to match. In the "Embedded" EGL-FB (Linux EGL/GLes direct
> framebuffer) case, we only have a single GL context to use for the whole
> framebuffer, so at least in that particular case you need a sharing
> mechanism.
> Dave

More information about the openjfx-dev mailing list