Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8126802

FB: Dynamic loading of Prism es2 and embedded EGL platforms



      On embedded platforms, the library libGLESv2.so and libEGL.so may be implemented by different vendors. This causes problems when we are trying to support multiple vendors impls with a common binary. The ARM eJRE manages to support a broad range of Linux ARM platforms because it can rely on a common set of libraries that it can be built with.

      For GLES, I have tested a proof of concept native application that links only with common libraries (though X11 when needed), and dynamically loads EGL and GLES. This same binary was shown to run on several of the major vendors (TI, Freescale) and probably will work with Broadcom after some additional platform initialization tweaks are added. This works because the dynamic resolution of the function pointers avoids the symbols resolution issue.

      For us to use this trick with JFX, we need to dynamically load :
         * the EGL symbols which is in platform specific code
         * the GL symbols which is in common code
      The common code has about 1/2 of the 40 symbols used dynamically loaded and the rest resolved at link time.

      For embedded, I would prefer one or the other. With a simple header trick we could replace all of the GL calls with calls through a function pointer, and just initialize those pointers before first use, using headers like this:
      PORTEGLAPI EGLBoolean (*_eglMakeCurrent_func)(EGLDisplay dpy, EGLSurface draw,
                                EGLSurface read, EGLContext ctx);
      #define eglMakeCurrent(dpy,draw,read,ctx) (*_eglMakeCurrent_func)(dpy,draw,read,ctx)

      We need to know what the architecture direction is soon so that we can make our plans.




            • Assignee:
              kselle Lisa Selle (Inactive)
              ddhill David Hill (Inactive)
            • Votes:
              0 Vote for this issue
              7 Start watching this issue


              • Created: