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

Unpredictable results of createMultiResolutionScreen with multimonitor multiDPIs

XMLWordPrintable

    • x86_64
    • windows_10

      ADDITIONAL SYSTEM INFORMATION :
      Windows 10 Pro build 18363
      OpenJDK 15.0.2

      A DESCRIPTION OF THE PROBLEM :
      When having a multimonitor multi scale setup, the resulting image of createMultiResolutionScreen is unpredictable:
      - It can be a smaller crop than expected image
      - It can be a bigger crop than expected
      - It can be offset
      - It can be exactly as expected

      All of this depends on the input rectangle's center scale.
      If the center of the rectangle is in a screen which scale is set to 100% -> the result is a crop with the exact real bounds as the input.
      If the center is in a high dpi screen with 200% scale -> the resulting highRes image will be 200% bigger than the input rectangle, with a bigger crop than expected.

      I can provide a much more detailed report in PDF with samples.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Have 2 displays, one with 100% scale the other with 200% scale.
      Center point in real resolution should be on the 100% display; while center point with scaled down coordinates (while being at the monitor with 200% scaling, window's bounds are scaled respectively) should be at the display with 200% scaling.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      When using real bounds -> get a full multiu-screen capture (exactly like Print Screen works)
      ACTUAL -
      Image is double it's size, with black bands on the sides (the crop is outside real dimensions).

      CUSTOMER SUBMITTED WORKAROUND :
      Implementing a predictable Robot screen capture method:

      private synchronized BufferedImage
      createNativeScreenCapture(Rectangle screenRect) {
          BufferedImage highResolutionImage;
          DataBufferInt buffer;
          WritableRaster raster;

          if (screenCapCM == null) {
              /*
               * Fix for 4285201
               * Create a DirectColorModel equivalent to the default RGB ColorModel,
               * except with no Alpha component.
               */

              screenCapCM = new DirectColorModel(24,
                      /* red mask */ 0x00FF0000,
                      /* green mask */ 0x0000FF00,
                      /* blue mask */ 0x000000FF);
          }

          int[] bandmasks = new int[3];
          bandmasks[0] = screenCapCM.getRedMask();
          bandmasks[1] = screenCapCM.getGreenMask();
          bandmasks[2] = screenCapCM.getBlueMask();

          // need to sync the toolkit prior to grabbing the pixels since in some
          // cases rendering to the screen may be delayed
          Toolkit.getDefaultToolkit().sync();

          int[] pixels;

          pixels = peer.getRGBPixels(screenRect);
          buffer = new DataBufferInt(pixels, pixels.length);

          bandmasks[0] = screenCapCM.getRedMask();
          bandmasks[1] = screenCapCM.getGreenMask();
          bandmasks[2] = screenCapCM.getBlueMask();

          raster = Raster.createPackedRaster(buffer, screenRect.width,
                  screenRect.height, screenRect.width, bandmasks, null);
          SunWritableRaster.makeTrackable(buffer);

          highResolutionImage = new BufferedImage(screenCapCM, raster,
                  false, null);

          return highResolutionImage;
      }


      FREQUENCY : occasionally


            honkar Harshitha Onkar
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: