There is also something that we should be aware of. The external graphic context is a fragile thing. In our case, for example with OpenGL, it was very easy to create problems with the Java app which try to paint things on the context. Which can lead to crashes or artefacts.
Le mer. 17 févr. 2021 à 12:06, Neil C Smith <n...@codelerity.com> a écrit : > On Tue, 16 Feb 2021 at 23:33, Michael Strauß <michaelstr...@gmail.com> > wrote: > > The main problem with this idea is that there is no universally available > > hardware rendering backend in JavaFX. There's OpenGL on Linux and macOS, > > Direct3D on Windows, and potentially a software renderer on all > platforms. > > How is that a problem? Not all platforms support PosixFilePermissions > either. I used that io -> nio2 comparison because of that similar > choice of lowest denominator abstraction as opposed to an API for > querying capabilities and exposing them if available. Most, if not > all, of the use cases here are about interaction with libraries using > native components that are either not universally available or provide > platform-specific alternatives too? > > Incidentally, does the OpenGL renderer not work on Windows at all, or > just not get used by default? Can't remember. > > > It is generally not safe to expose the OpenGL rendering context > > that is used internally by JavaFX, because users might inadvertently > change > > the GL state machine. > > Why is that actually a problem? Surely caveat emptor has to apply > here? And potentially access can be managed within scopes that > require permissions, push/pop state, etc if required? > > 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 >
