Hi Mark, On Tue, 16 Feb 2021 at 15:27, Mark Raynsford <org.open...@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
