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

Changes to image data should be tracked at a finer granularity

XMLWordPrintable

    • 2d
    • b08
    • generic, x86
    • generic, linux, solaris_9
    • Verified

        The graphics implementation tracks changes to image objects so that it
        can determine when to cache the data in an accelerated surface and when
        those cached versions are out of date.

        Currently that tracking is performed at the Raster level and requires
        strict ownership of the DataBuffer and the data arrays in the DataBuffer.
        This means that any code that attempts to dig into an image to get its
        DataBuffer or any attempt to create multiple Rasters and Images which
        share a DataBuffer will result in those images being ineligible for
        acceleration via our CachingSurfaceManager.

        Various proposals have been suggested to turn off this mechanism and make
        the default assumption that all image data is cacheable regardless of
        how exposed the pixel data is because the existing mechanism will be
        unable to track the changes under a variety of circumstances that turn
        out to be common or important to a growing number of developers.

        Also, change tracking is only available via the internal hidden Raster
        classes in the sun.* hierarchy which cannot be accessed by code outside
        the JDK.

        If the tracking is moved to a lower layer then more interfaces in the
        java.awt.image package could be used by developers without the undesired
        result of yielding unacceleratable images. Minimally this involves:

        - Moving the change tracking down into the DataBuffer class from the
        internal SunWritableRaster classes.

        - Providing an interface for modifying the pixels in an image - presumably
        at the DataBuffer level - that interacts well with the change tracking
        mechanisms with reasonable performance.

        - Verifying that the code in the JDK is "change tracking compatible" by
        finding cases where we currently violate the assumptions of the current
        change tracking mechanism and making sure that they will be compatible
        with the assumptions of the new mechanism. This implicitly assumes that
        we will also verify that we have created no new cases which violate the
        new rules of the new change tracking mechanism.
        ###@###.### 2004-12-08 02:05:11 GMT
        ###@###.### 2004-12-08 02:37:01 GMT

              flar Jim Graham
              flar Jim Graham
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: