java3d
  1. java3d
  2. JAVA3D-596

General rendering issues with dual screen

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.1
    • Fix Version/s: not determined
    • Component/s: j3d-core
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: PC

    • Issuezilla Id:
      596

      Description

      While working myself through the 3D-API, I found a problem with the rendering on
      multi-screen workstations, as myself one is with a notebook and an external monitor.
      The problem occurs on Windows Vista as well as on Windows XP. I tested
      thoroughly on Vista. (haven't tested on any other OS though)

      When starting a J3D-application, it starts where I intended it to start. If
      there is an animation, the animation starts, but may abruptly stop. The
      rendering is either continued on another part of the dual-screen, is continued
      invisibly, or is being continued on parts of the screen. (for example, it may
      render over an open Skype-window, or over the mailclient; however, it always
      renders on the same monitor, the application-window currently is on. There is no
      rendering on the secondary screen, while the window resides on the primary
      screen and vice versa)
      When moving the application to the secondary screen, the rendering usually is
      resumed within the window (working properly again - for a short period). Moving
      it back to the primary monitor usually presents the window in the
      background-color of the universe.
      The same is true when starting the program as an applet (for example, using the
      Eclipse-functionality to run the program either as an applet within an
      applet-viewer or as an application)

      Running the applet within a browser, it presents the exact same behavior as
      described by Issue 361 and it's comments. Therefore, those two issues may be
      related to each other.

      Normally, I'd think that this would be a problem within my applications, but
      this behavior occurs with the J3D-Sample programs and the programs from the Java
      3D-Tutorial as well. However, the rendering is more likely to fail if there is
      user action involved.
      For example, the "KeyNavigatorApp" from the Tutorials is almost guaranteed to
      fail while moving around, whereas "static" examples like the "AxisApp" seem to
      not fail at all.

      Even after terminating the application, there are black spots all over the
      screen, where the application has rendered itself. This link
      (http://www1.siconet.at/Kastna/stuff/rendering.jpg) shows my Skype-window, after
      the application rendered itself partly over it. (there are actually names
      visible, I just white-blanked 'em out. The black spots are the ones, that were
      created by the application)

      What confuses me most, is, that this behavior also appears, even if the
      secondary screen is disabled (by not extending the desktop to the secondary
      screen in the windows display-settings). Although I have to add, that the screen
      was still connected to the notebook (via a docking station).

      There also seems to be a correlation between the runtime of the operating system
      and the frequency of the issue to appear: The longer a system is up, the more
      likely it is, that the rendering fails, but that may be a subjective opinion.

        Activity

        Hide
        aces added a comment -

        Hi

        try to create your canvas 3D using below code:

        /**

        • Creates a Canvas3D instance.<br>
        • This method targets multi screen systems, where Canvas3D may be
        • placed in other Screen then DefaultScreen device.
          *
        • @param compForCanvas - Component which will hold-on a Canvas3D. If null or
        • not yet added to a container, this method will use
        • default screen device.<br>
        • The parameter compForCanvas can be an instance of java.applet.Applet,
        • java.awt.Window, java.awt.Frame, javax.swing.JFrame and their sub-classes,
        • as well an instance of JPanel already attached to one of previous cited
          Containers.
        • @return a Canvas3D instance multi-screen/multi-head aware.
        • */
          public static Canvas3D createCanvas3D(java.awt.Component compForCanvas) {
          GraphicsDevice graphicsDevice;

        if (compForCanvas.getGraphicsConfiguration() != null)

        { // component is, or belongs to, a live container graphicsDevice = compForCanvas.getGraphicsConfiguration().getDevice(); }

        else

        { // component is not alive yet, use default graphics device graphicsDevice = GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice(); }

        GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D();
        // change template settings here
        //template.setSceneAntialiasing(GraphicsConfigTemplate3D.PREFERRED);

        GraphicsConfiguration config = graphicsDevice.getBestConfiguration(template);

        return new Canvas3D(config);
        }

        Show
        aces added a comment - Hi try to create your canvas 3D using below code: /** Creates a Canvas3D instance.<br> This method targets multi screen systems, where Canvas3D may be placed in other Screen then DefaultScreen device. * @param compForCanvas - Component which will hold-on a Canvas3D. If null or not yet added to a container, this method will use default screen device.<br> The parameter compForCanvas can be an instance of java.applet.Applet, java.awt.Window, java.awt.Frame, javax.swing.JFrame and their sub-classes, as well an instance of JPanel already attached to one of previous cited Containers. @return a Canvas3D instance multi-screen/multi-head aware. */ public static Canvas3D createCanvas3D(java.awt.Component compForCanvas) { GraphicsDevice graphicsDevice; if (compForCanvas.getGraphicsConfiguration() != null) { // component is, or belongs to, a live container graphicsDevice = compForCanvas.getGraphicsConfiguration().getDevice(); } else { // component is not alive yet, use default graphics device graphicsDevice = GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice(); } GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D(); // change template settings here //template.setSceneAntialiasing(GraphicsConfigTemplate3D.PREFERRED); GraphicsConfiguration config = graphicsDevice.getBestConfiguration(template); return new Canvas3D(config); }
        Hide
        mondaymassacre added a comment -

        Unfortunately, this does not work either. I still encounter the same issues.

        I combined your method with the one proposed in the ocmments of Issue 361 (where
        the Graphics Configuration is returned) by setting the stereo-property (see code).

        What get's more and more clearly to me now is, that, starting the application as
        an applet, it seems that it also has a lot of troubles processing the input:
        applet-mouse-input is processed with less accuracy than application-mouse-input
        and application-mouse-input is processed with less accuracy when the application
        is moved to secondary screen.
        applet-keyboard-input is ignored completely, but seems to interfere with the
        accuracy of the mouse-input.

        -8<--------------------------------------------------------------------------

        public static Canvas3D createCanvas3D(java.awt.Component compForCanvas)
        {
        GraphicsDevice graphicsDevice;

        if (compForCanvas.getGraphicsConfiguration() != null)

        { // component is, or belongs to, a live container graphicsDevice = compForCanvas.getGraphicsConfiguration().getDevice(); }

        else

        { // component is not alive yet, use default graphics device graphicsDevice = GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice(); }

        GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D();
        String stereo = (String) java.security.AccessController
        .doPrivileged(new java.security.PrivilegedAction()
        {
        public Object run()

        { return System.getProperty("j3d.stereo"); }

        });

        // update template based on properties.
        if (stereo != null)

        { if (stereo.equals("REQUIRED")) template.setStereo(GraphicsConfigTemplate3D.REQUIRED); else if (stereo.equals("PREFERRED")) template.setStereo(GraphicsConfigTemplate3D.PREFERRED); }

        // change template settings here
        template.setSceneAntialiasing(GraphicsConfigTemplate3D.PREFERRED);

        GraphicsConfiguration config = graphicsDevice.getBestConfiguration(template);

        return new Canvas3D(config);
        }

        Show
        mondaymassacre added a comment - Unfortunately, this does not work either. I still encounter the same issues. I combined your method with the one proposed in the ocmments of Issue 361 (where the Graphics Configuration is returned) by setting the stereo-property (see code). What get's more and more clearly to me now is, that, starting the application as an applet, it seems that it also has a lot of troubles processing the input: applet-mouse-input is processed with less accuracy than application-mouse-input and application-mouse-input is processed with less accuracy when the application is moved to secondary screen. applet-keyboard-input is ignored completely, but seems to interfere with the accuracy of the mouse-input. - 8< -------------------------------------------------------------------------- public static Canvas3D createCanvas3D(java.awt.Component compForCanvas) { GraphicsDevice graphicsDevice; if (compForCanvas.getGraphicsConfiguration() != null) { // component is, or belongs to, a live container graphicsDevice = compForCanvas.getGraphicsConfiguration().getDevice(); } else { // component is not alive yet, use default graphics device graphicsDevice = GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice(); } GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D(); String stereo = (String) java.security.AccessController .doPrivileged(new java.security.PrivilegedAction() { public Object run() { return System.getProperty("j3d.stereo"); } }); // update template based on properties. if (stereo != null) { if (stereo.equals("REQUIRED")) template.setStereo(GraphicsConfigTemplate3D.REQUIRED); else if (stereo.equals("PREFERRED")) template.setStereo(GraphicsConfigTemplate3D.PREFERRED); } // change template settings here template.setSceneAntialiasing(GraphicsConfigTemplate3D.PREFERRED); GraphicsConfiguration config = graphicsDevice.getBestConfiguration(template); return new Canvas3D(config); }
        Hide
        mondaymassacre added a comment -

        Okay, I could narrow the problem down.
        Today I tested my app on my boss' machine who also has Windows Vista and it
        surprisingly worked flawlessly. Then I turned on the Aero interface on my
        machine at it also worked. So there is a problem on Vista, when the
        Aero-interface is turned off. It also works without the workaround suggested
        in this thread and issue 361.

        Then I re-checked my application on a Windows XP PC and the rendering issues
        didn't occur, although the mouse-input wasn't captured well when it was on the
        primary screen. In general, the sample rate of the mouse was a lot lower on XP
        than it was on Vista.

        All three machines were VGA dual monitor systems, connected to the monitor via a
        Docking Station.

        So there are actually two open questions:
        1) Why would there occur rendering-issues on Windows Vista, when the
        Aero-interface is turned off.
        2) Why is the sample rate of the mouse on XP machines much lower than on Vista
        machines?

        Show
        mondaymassacre added a comment - Okay, I could narrow the problem down. Today I tested my app on my boss' machine who also has Windows Vista and it surprisingly worked flawlessly. Then I turned on the Aero interface on my machine at it also worked. So there is a problem on Vista, when the Aero-interface is turned off . It also works without the workaround suggested in this thread and issue 361. Then I re-checked my application on a Windows XP PC and the rendering issues didn't occur, although the mouse-input wasn't captured well when it was on the primary screen. In general, the sample rate of the mouse was a lot lower on XP than it was on Vista. All three machines were VGA dual monitor systems, connected to the monitor via a Docking Station. So there are actually two open questions: 1) Why would there occur rendering-issues on Windows Vista, when the Aero-interface is turned off. 2) Why is the sample rate of the mouse on XP machines much lower than on Vista machines?
        Hide
        aces added a comment -

        Try to run with DirectDraw disabled for 2D, i.e., AWT / Swing.
        To archive this use below JVM option :
        -Dsun.java2d.noddraw=false

        Show
        aces added a comment - Try to run with DirectDraw disabled for 2D, i.e., AWT / Swing. To archive this use below JVM option : -Dsun.java2d.noddraw=false
        Hide
        mondaymassacre added a comment -

        Still no improvement

        Show
        mondaymassacre added a comment - Still no improvement

          People

          • Assignee:
            java3d-issues
            Reporter:
            mondaymassacre
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: