#2 OpenGL ES support

open
nobody
None
5
2014-11-11
2013-08-22
No

Howdy all!

I think the title of the feature request says it all : D I know next to nothing about OpenGL in general, and I imagine that this request might be tough as nails, since there's no GLUT on embedded systems, but I'm more than willing to learn the codebase and try doing some of the footwork myself if you folk think that GLES support is possible.

As for why, GLES support is essential for running things on the raspberry pi, or, more importantly to me, creating no-java-just-perl android apps.

Related

Feature Requests: #2

Discussion

  • Chris Marshall

    Chris Marshall - 2013-08-22

    Work is underway to update POGL to the
    latest OpenGL 4.x API features. I think that
    OpenGLES is a subset of that functionality.

    --Chris

    On Thu, Aug 22, 2013 at 2:40 AM, Brian Fraser hugmeir@users.sf.net wrote:


    [feature-requests:#2] OpenGL ES support

    Status: open
    Created: Thu Aug 22, 2013 02:40 AM UTC by Brian Fraser
    Last Updated: Thu Aug 22, 2013 02:40 AM UTC
    Owner: nobody

    Howdy all!

    I think the title of the feature request says it all : D I know next to
    nothing about OpenGL in general, and I imagine that this request might be
    tough as nails, since there's no GLUT on embedded systems, but I'm more than
    willing to learn the codebase and try doing some of the footwork myself if
    you folk think that GLES support is possible.

    As for why, GLES support is essential for running things on the raspberry
    pi, or, more importantly to me, creating no-java-just-perl android apps.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/pogl/feature-requests/2/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Feature Requests: #2

  • ddumont

    ddumont - 2014-11-11

    Hmm, I think that GLES is already a subset of existing OpenGL API. (See http://en.wikipedia.org/wiki/OpenGL_ES and http://web.eecs.umich.edu/~sugih/courses/eecs487/common/notes/APITables.xml )

    On linux, gles is provided by libGLESv2.so.2 . POGL is not linked to that library.

    I think (well, I hope), that supporting GLES would require:
    - be able to link POGL to libGLESv2.so instead of libglut.so
    - be able to #ifdef out all OpenGL only function definitions in XS files

    Of course, I may be completely wrong...

    What do you think ?

    All the best

     
    • Chris Marshall

      Chris Marshall - 2014-11-11

      The current POGL bindings are hand generated XS wrappers that cover OpenGL functionality up to OpenGL 2.x-ish. This has the problem that they are determined at build time and not at run time so there is a possible issue of functionality that might be available (or not) at build time but differs at run time.

      The planned solution is to use the GLEW library to generated the POGL bindings that would be able to be determined at run time. This gives dynamic bindings and full support for all features and extensions up through OpenGL 4.x.

      I'm not familiar enough with the modern OpenGL vs OpenGL ES stuff to understand how this would need to change for the use of OpenGL ES rather than OpenGL. Maybe a similar strategy to the GLEW one could be used there.

      Regarding GLUT, that was added in an attempt to move POGL from the original X11 base implementation to one that is portable across platforms. While it did achieve that goal, it also added a false requirement on FreeGLUT to perl modules using OpenGL.

      The plan for the POGL update is to spin off the user interface/context generation part into separate modules with a generic plugin type approach. That would allow one to use any of a number of options for platform interfaces: X11, GLUT, GLFW, Qt, wxWidgets, or any other library that can provide the needed graphic context.

       
  • ddumont

    ddumont - 2014-11-11

    There's a discussion with patches about glew and gles integration. Unfortunately, the conlusion of this thread is not really in favor of gles integration:

    I'd be a bit concerned on mobile platforms that the full desktop GLEW would be trying to load all kinds of irrelevant desktop extensions for OpenGL ES, and resulting in a much larger footprint than necessary.

    And there's no mention of gles in glew changelog.

    I'm beginning to wonder if supporting gles as part of pogl is the right solution. May be a new set of bindings would be better...

     
    • Chris Marshall

      Chris Marshall - 2014-11-11

      I think the telling point is that GLEW handles everything but the
      point of GL ES is to support embedded platforms which are resource
      sensitive. To that end, specific bindings for OpenGL::ES would make a
      lot of sense. The build could focus on bindings only for GLES
      functions and defines which should keep things much smaller than full
      OpenGL/GLEW support.

      Ideally, the implementation would be interoperable with the full
      OpenGL bindings provided one sticks to the relevant GLES subset. I
      like the no-java-just-perl apps approach....

      On Tue, Nov 11, 2014 at 2:01 PM, ddumont ddumont@users.sf.net wrote:

      There's a discussion with patches about glew and gles integration.
      Unfortunately, the conlusion of this thread is not really in favor of gles
      integration:

      I'd be a bit concerned on mobile platforms that the full desktop GLEW would
      be trying to load all kinds of irrelevant desktop extensions for OpenGL ES,
      and resulting in a much larger footprint than necessary.

      And there's no mention of gles in glew changelog.

      I'm beginning to wonder if supporting gles as part of pogl is the right
      solution. May be a new set of bindings would be better...

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks