On Sun, 7 Mar 2021 at 15:36, Mark Raynsford <org.open...@io7m.com> wrote: > The basic primitive > that would be required is "transfer this image to this other image". > You'd need to expose that operation in way that would work for every > possible pair of rendering APIs ... The complexity of handling that would > need to be pushed onto > each person trying to use the API.
Surely that is the point? I'm also not sure what you mean by "pair of rendering APIs", or why you'd want to try and support every possible pairing internally in JavaFX? > JavaFX would effectively need to > know when it was safe to use an image that was being transferred in, > without actually being able to know where the image was coming from or > who to talk to about it. The only methods it _could_ use would involve > CPU-side fences, which would then have performance implications. CPU-side fences may be required, yes. The problem you outline is already the problem we have, and have had to hack around, with the PixelBuffer API. That already lacks a way to tell JavaFX that the backing memory is no longer safe to use, or for JavaFX to communicate back that the memory is safe to reclaim - it's uni-directional. Somehow, that really needs to be made bi-directional, such that either side can take ownership and release the data as necessary. Solve that issue and you're possibly on the way to solving the same safe / unsafe concerns raised here? So, yes, potentially performance implications over complete unfettered access, no doubt. > > > Traditional stateful APIs like > > > OpenGL make it far too easy for external code to screw up the > > > rendering context anyway, so exposing JavaFX's own context would > > > be a bad idea. > > > > I remain of the view that this shouldn't really be that concerning?! > > It's a bug in the library if it does so. > > It's definitely concerning. Have you worked with OpenGL much? Yes, quite a lot. I mean "concerning" specifically to the JavaFX project, not to the library developer making use of the ability. I realise that it's a fine line to draw between the amount of access you provide, the amount you hinder future evolution, the amount you make certain use cases unviable, and the amount you allow users to shoot themselves in the foot. Best wishes, 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
