Hi, On Tue, 25 Feb 2020 at 13:25, Kevin Rushforth <[email protected]> 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
