PixelBuffer API threading model?

[Neil C Smith]

Hi,

On Tue, 25 Feb 2020 at 13:25, Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
> This points out a flaw in the specification.
...
> To answer your other question about adding an API to PixelBuffer to swap
> out the underlying Buffer (to avoid yet another copy), I'm not sure how
> hard that would be (we currently assume that the buffer object itself is
> immutable)

Thanks for the info.  The code I'm working on is loosely ported from
some existing code that interfaces GStreamer with OpenGL texture
upload.  In there, we have a small amount of locking between the
GStreamer callback and the OpenGL thread to cover buffer swap and
texture upload.  Being able to do likewise with the PixelBuffer API,
to swap or null the underlying buffer, would cover both use cases
here?  Swapping the underlying buffer also makes sense for a number of
APIs like GStreamer that ping pong between various memory locations,
otherwise we need to do some careful image caching.

> I'm not 100% sure that
> running it in a Platform.runLater is sufficient in all cases, but will
> file a bug to investigate the threading and to document when it is safe
> to free a native DirectBuffer. It would still be useful to have your
> test case, too.

OK, will do.  I've run a "battle test" with 4k textures at 60fps,
freeing the whole native pipeline every 5sec.  Without
Platform::runLater it segfaults almost immediately.  Moving the free
into Platform::runLater seems to run happily for hours.  Caveat,
caveat, YMMV, etc. :-)

Many thanks,

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