Hi Neil,
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.
-- Kevin
On 2/25/2020 2:42 AM, Neil C Smith wrote:
On Fri, 21 Feb 2020 at 12:39, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
I missed seeing this yesterday. Since you have a test program, can you
file a bug at:
https://urldefense.com/v3/__https://bugreport.java.com/__;!!GqivPVa7Brio!NbvpernCUtnKGCczrvpk22da9xKbHFu64OIolCd86BxXnVxOT2HFW47wx97PiUPVtuUh$
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,
Neil
