On 2021-03-07T12:22:11 +0000 Neil C Smith <n...@codelerity.com> wrote:
> Hi, > > A few comments from my perspective here, mainly coming from > frustration at the number of times I've had to tell clients or users > that JavaFX isn't a viable option for them .. > > On Sat, 6 Mar 2021 at 12:22, Mark Raynsford <org.open...@io7m.com> wrote: > > there is a > > combinatorial explosion of possibilities with regards to which > > rendering API the _user_ might be using, and which rendering API > > JavaFX might be using (if any!). > > I agree that's a difficult one, but also surely not an insurmountable > one?! There are precedents around Java APIs that provide querying and > access to optional support on a platform by platform basis... I think it's insurmountable due to the complexity of the semantics of the thing (the GPU) that's being abstracted over. 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, including getting all of the synchronization right that lower level APIs like Vulkan and DX12 require. The complexity of handling that would need to be pushed onto each person trying to use the API. 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. To clarify a bit: Let's say we lived in an ideal world and JavaFX had a Vulkan backend, and contained code that was willing to cooperate with the user's Vulkan-based rendering code. The user could tell JavaFX "here's the image to use for this node, but don't use it until this semaphore becomes available". This is generally highly efficient as a semaphore (in Vulkan terms) is a GPU-side primitive that just controls parallelism across different queue instances on the GPU, with no CPU-side interaction at all. We have no way to get to that ideal world whilst JavaFX and the user's code have no common API over which to communicate. Everything would have to go via CPU-based abstractions. > > 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? If you're *lucky* you'll get a crash, because at least then you'll see the exact location where the mistake occured. What you'll typically get instead is corrupted rendering, a black screen, or just bad performance as the driver desperately tries to make sense of what you asked it to do, usually in completely unrelated parts of the rendering process. It's the prime reason I jumped ship to Vulkan the second it came out. :) > > JavaFX _does_ have a software renderer. What if we could have JavaFX > > work with entirely software rendering into an offscreen BufferedImage? > > Why BufferedImage? What about a reuse / extension / parallel of > PixelBuffer? Yes indeed. I said BufferedImage just because I assumed that would be more familiar. I'd not personally care where the output went as long as I could get the raw bytes out of it in order to upload to the GPU. -- Mark Raynsford | https://www.io7m.com
