Would removal of this break anything on other platforms (OS or hardware [embedded/non-embedded], Wayland)? Assume since focused x11 (mainly Unix platforms) it shouldn’t but figured I’d ask.
A little off topic but is an architecture diagram with applicable elements available someplace? If not am I correct in saying from a high to lower layer there is - Prism - which renders scenes. A believe this was deprecated/removed at some point in more recent updated - ES2 - provide acceleration (possibly hardware if supporting) - GL - open gl for graphical / harder rendering - X11 - UNIX windowing client/server protocols communications between - Monocle - the “glass” layer where the above are rendered - OS/Kernel Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On January 18, 2021 at 2:38:17 AM CST, Johan Vos <johan....@gluonhq.com > (mailto:johan....@gluonhq.com)> wrote: > Related to this question, there is the comment from Kevin about removing > references to es2-eglfb/es2-eglx11 in other files, e.g. ES2Pipeline.java [1] > While I believe this is a good idea, it opens room for more cleanup (or at > least more consistency): > In some cases, library names indicate a configuration. For example, > prism-es2-monocle indicates that the glass-platform monocle is used. In > most cases though, the library names do not contain this information. On > mac/linux/windows/ios, we simply use prism-es2 . Obviously, the contents of > the library vary for the different platforms, but this is taken care of by > the build process. > > This inconsistency leads to avoidable logic in the Java classes, e.g. in > ES2Pipeline. After cleaning up for the unused egl{fb,x11} variants, there > will still be a check about which library should be loaded: if the glass > variant is monocle, prism-es2-monocle is loaded. In all other cases, > prism-es2 is loaded. > I think the name of the library should either always contain the glass > variant name, or never. I have a preference for removing the variant in the > name completely, as this will allow us to remove even more logic in the > .java files. > > [1] https://github.com/openjdk/jfx/pull/378#issuecomment-761673755 > > > On Sat, Jan 16, 2021 at 1:26 PM Johan Vos <johan....@gluonhq.com > (mailto:johan....@gluonhq.com)> wrote: > > > I would guess those were used before Monocle was introduced. > > > > On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker <nlis...@gmail.com > > (mailto:nlis...@gmail.com)> wrote: > > > > > Out of curiosity, what were they used for? > > > > > > On Thu, Jan 14, 2021 at 3:54 PM Johan Vos <johan....@gluonhq.com > > > (mailto:johan....@gluonhq.com)> wrote: > > > > > > > Hi, > > > > > > > > We currently have a number of GLFactory implementations in the ES2 Prism > > > > pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we > > > > use > > > > X11, and systems with monocle can use either egl, X11, fb,... but that > > > > is > > > > then managed by the MonocleGLFactory. > > > > > > > > Unless these files are used, I suggest they are removed (that is the > > > > java > > > > classes and the native code). > > > > > > > > The static initialiser of GLFactory will then have only 2 choices for > > > > factoryClasses that can be used on Linux: X11, or Monocle. The latter is > > > > only used if the System Property `embedded` is set to `monocle` (as > > > > checked > > > > in PlatformUtil). We can replace this in a check on the Glass platform > > > > (which is already done in Glass: com.sun.glass.ui.Platform will check > > > > the > > > > value of `glass.platform`, and Monocle will be selected in Glass in case > > > > the value is set to `Monocle`.) > > > > Clearly, Prism and Glass are 2 different things, but I personally would > > > > prefer to have the decision whether to use X11 or Monocle to be based on > > > > this `glass.platform` property rather then on yet another property > > > > (`embedded`) that is apart from this not used for anything else. > > > > > > > > I will create an issue for this, but in case I'm missing something, > > > > please > > > > let me know. > > > > > > > > - Johan > > > > > > >
