cleanup obsolete code

Eric Bresie ebresie at gmail.com
Thu Jan 21 13:18:53 UTC 2021


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
Ebresie at gmail.com (mailto:Ebresie at gmail.com)

> On January 18, 2021 at 2:38:17 AM CST, Johan Vos <johan.vos at gluonhq.com (mailto:johan.vos at 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.vos at gluonhq.com (mailto:johan.vos at gluonhq.com)> wrote:
>
> > I would guess those were used before Monocle was introduced.
> >
> > On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker <nlisker at gmail.com (mailto:nlisker at gmail.com)> wrote:
> >
> > > Out of curiosity, what were they used for?
> > >
> > > On Thu, Jan 14, 2021 at 3:54 PM Johan Vos <johan.vos at gluonhq.com (mailto:johan.vos at 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
> > > >
> > >


More information about the openjfx-dev mailing list