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

Flickering upon resize in Mustang

    XMLWordPrintable

Details

    • b62
    • generic, x86
    • windows, windows_xp

    Backports

      Description

        In Mustang, dynamic layout of the AWT toolkit was changed to default
        to true. This has caused severe flickering when using the JOGL library
        (http://jogl.dev.java.net) when resizing windows containing JOGL's
        GLCanvas.

        JOGL subclasses Canvas into GLCanvas, which overrides paint(Graphics)
        and update(Graphics) in order to prevent the core toolkit from
        rendering into the Canvas, since all of the rendering is done via
        OpenGL using the JAWT. However, this doesn't disable all of the places
        the AWT and Java2D attempt to draw into a Canvas.

        The problem is the presence of the default background erasure which is
        disabled by specifying -Dsun.awt.noerasebackground=true
        (WCanvasPeer.java). Specifying this flag fixes the flickering problem.
        However, it is not correct to specify this flag for all applications
        since their repainting behavior may vary. For this reason we can't
        simply force this flag to true whenever JOGL is being used.
        (Applications can do so, but we don't have the option of turning it on
        automatically in the JOGL library.)

        The best solution would be to disable the erasure of the background on
        a per-Canvas basis. I've looked through the related Windows peer code
        and due to the use of package-private constructors I don't see a way
        to get code in between the Canvas and its WCanvasPeer. One thought I
        had was to wrap the WCanvasPeer with another WComponentPeer subclass
        which would delegate all operations to the contained WCanvasPeer
        except return false for shouldClearRectBeforePaint(). I might be able
        to make this work by trying to claim that my workaround class lives in
        the sun.awt.windows package, but this seems like a really bad hack.

        The best solution I can think of at this point would be to add an API
        to the Canvas class like

          public boolean shouldEraseBackgroundBeforePaint();

        This API should be documented as having platform-specific behavior
        (i.e., may not be consulted on all platforms -- the noerasebackground
        property only has an effect on Windows as far as I can tell) and the
        implementation of WCanvasPeer should be changed to ask its Canvas as
        well as look at the globally-specified property. If either says to not
        erase the background, return false from
        WCanvasPeer.shouldClearRectBeforePaint().

        Since this is a small API and implementation change, does not affect
        any existing applications, and solves a serious flickering problem in
        a general way, it is low risk and should be able to be fixed in
        Mustang.

        Attachments

          Issue Links

            Activity

              People

                agerasimsunw Alexander Gerasimov (Inactive)
                kbr Kenneth Russell (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: