Layering JavaFX onto an external rendering context

[Neil C Smith]

Hi Mark,

On Tue, 16 Feb 2021 at 15:27, Mark Raynsford <org.openjdk at io7m.com> wrote:
> But it seems to me like those projects shouldn't _have_ to exist. It
> seems like a bit of a design flaw that there isn't an efficient code
> path to do something (relatively) simple like this.
>
> Has anyone given any thought as to what an API like this should look
> like?

I agree with you, and have certain similar requirements, like being
able to allow GStreamer and JavaFX to share GPU contexts.  In fact,
was bugging Johan about this in the chat around his FOSDEM talk, and
promised to follow up here, so might as well pop my head above the
parapet. :-)

I certainly don't know what such an API should look like, but in some
ways to me parallels the differences between io file and nio2 files -
hidden by abstraction vs type-safe queryable capabilities / profiles.
In fact, given above, also something slightly akin to GStreamer's
context querying.

Incidentally, reading your initial post about PixelBuffer reminds me
that I should also follow up on a point about concurrency issues with
that from last year.  The API has (or had?) issues with accessing the
buffer from the rendering thread after it's been removed in the event
thread, which particularly with externally allocated buffers makes it
hard to safely mark as invalid to allow them to be freed.

Best wishes,

Neil

-- 
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669
Registered office address : Office 4 219 Kensington High Street,
Kensington, London, England, W8 6BD