PixelBuffer API threading model?
kevin.rushforth at oracle.com
Tue Feb 25 13:25:14 UTC 2020
I didn't look at your use case in detail, so I missed that you were
talking about freeing the native memory that is backing your
DirectBuffer. No, freeing the memory immediately after calling
setImage(null) will not work. The JavaFX rendering is done in a
different thread, which could still be using that buffer.
This points out a flaw in the specification. 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.
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). You can file an Enhancement request if you like, but isn't
likely to be done any time soon.
On 2/25/2020 2:42 AM, Neil C Smith wrote:
> On Fri, 21 Feb 2020 at 12:39, Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
>> I missed seeing this yesterday. Since you have a test program, can you
>> file a bug at:
>> and include your test case?
> Thanks Kevin. I need to replicate without a particular dependency,
> but will do ASAP. Can I confirm that the behaviour outlined in my
> first email is intended to be safe/supported usage then?
> Incidentally, this also means switching machines - my main dev machine
> with Mesa and an AMD GPU will kernel crash within about 40s using the
> PixelBuffer API. I'm fairly sure that's a Mesa bug but have not
> tracked down what exactly the API is doing that causes it - no issues
> with OpenGL code doing the same thing in principle.
> Best wishes,
More information about the openjfx-dev