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

Need API for accelerated offscreen surfaces

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P3 P3
    • 1.4.0
    • 1.4.0
    • client-libs
    • None
    • 2d
    • beta2
    • x86
    • windows_nt

      In order to get hardware acceleration for offscreen surfaces (such as those
      used for sprites and double-buffering), we need a new API that allows us
      to work with such objects. In particular, these types of hardware-accelerated
      surfaces are more volatile than existing Java images, and their contents
      could be destroyed at any time by circumstances beyond the control of
      Java or the application.

      We need new API calls that allow us to both create these kind of surfaces
      (telling Java that we want that particular image to be accelerated
      if possible) and deal with potential content-loss problems (ways for the
      user to know that contents have been lost and the means of restoring them).

      -----------
      There are additional requirements for this API, as specified in RFE's
      4379971 and 4379980. I am closing those RFE's as duplicates of this one and
      reopening this RFE. The descriptions from those RFE's follows:

      4379971:
      Currently, the new VolatileImage objects are implemented as subclasses
      of BufferedImage. This causes a problem with the specification of
      BufferedImage. In particular, a BufferedImage is created as a static object
      (with a static ColorModel, Raster, and SampleModel), whereas a VolatileImage
      can change at any time due to situations such as display mode switches.

      For example, if a user changes the bit depth setting (under Windows) we must
      recreate the data inside of the VolatileImage to be compatible with this
      new display depth (hardware surfaces must always be the same depth as the
      display surface).

      Because of this incompatibility, we need to make VolatileImage objects
      subclass off of Image instead, so that the user can assume nothing about
      the state or static nature of the image.

      4379980:
      VolatileImage currently has no means to help the user support multi-
      monitor situations. The problem is that VolatileImage objects are inherently
      tied to the device on which they were created (e.g., the video card of
      a particular display on Windows). When an app asks the VolatileImage to
      copy its contents to a different device (for example, if the app window
      moved to a different monitor or the app attempts to use one back buffer
      for several windows), this operation could fail but there is no way for
      VolatileImage to tell the user why it failed or what to do about it.


      chet.haase@Eng 2000-10-20

            chaasesunw Chet Haase (Inactive)
            chaasesunw Chet Haase (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: