Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: jogl
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      63

      Description

      My issue #62 is the result of trying to get a complicated multi-threaded approach
      to work with the assumption that the GLCanvas can only tell my app to do
      something through the GLEventListener interface. I'd prefer a simpler approach
      that skips those issues altogether.

      I'd really like only only thread (my rendering thread) to deal with Jogl. However, I
      do want to be able to render when the GLCanvas gets a paint event.

      This is my suggestion, though I'd be open to other ways of achieving the same
      thing:

      In GLCanvas.paint(), add an else condition to the if that checks the autoredraw
      mode. If autoredraws are turned off, call paint(g) on the GLCanvas's parent.

      This allows me to set up GLCanvas, turn off autoredraw, and have my paint
      method tell my rendering thread when it can go. Now I don't have to worry about
      thread synchronization issues trying to share Jogl between AWT calling display()
      and my rendering thread calling display(), and things are much cleaner.

      I first thought of asking for another method on the GLEventListener interface, but I
      don't want the call to go through invokeGL(), which is synchronized. Because I
      want to be in control of Jogl, I just want GLCanvas to let me know when it would
      have made a picture, so I could handle it in my own way (in addition to the way I
      initiate making a picture on my own).

      If there is a good way to handle this already, I'd be interested in hearing about it.
      I'm trying to fit this into a large existing system, so I can't make too many
      architectural changes to my own stuff.

      thanks
      andy

        Activity

        Hide
        kbr added a comment -

        The JSR-231 APIs have substantially revised the amount of control given to
        applications as well as significantly changed how operations such as forcing all
        GLAutoDrawable work on to a single thread are done. The NoAutoRedraw API has
        been completely removed from the JSR-231 APIs as it is no longer necessary for
        correctness. We believe the current JOGL implementation is significantly more
        robust than earlier versions and request you try the current version if still
        applicable.

        Show
        kbr added a comment - The JSR-231 APIs have substantially revised the amount of control given to applications as well as significantly changed how operations such as forcing all GLAutoDrawable work on to a single thread are done. The NoAutoRedraw API has been completely removed from the JSR-231 APIs as it is no longer necessary for correctness. We believe the current JOGL implementation is significantly more robust than earlier versions and request you try the current version if still applicable.

          People

          • Assignee:
            jogl-issues
            Reporter:
            andyskinner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: