PixelBuffer API threading model?

[Kevin Rushforth]

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.rushforth at 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
>
>