Integrating native Open GL code in JavaFX and alternatives

[Artem Ananiev]

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 
view.

Thanks,

Artem

> 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
>
>