Pivot
  1. Pivot
  2. PIVOT-390

issue for 'ColorChooser' Component

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 2.0
    • Component/s: wtk
    • Labels:
      None
    • Environment:
      Windows XP / Firefox 3.6 / JRE_1.6.0_18

      Description

      Attached zip file is a avi file, and txt file is my system environment info, I wish it will help.

      And your questions are answered in blue below.

      • What demo were you running (I assume Kitchen Sink)?

      all demos when 'ColorChooser' shows.

      • Does it happen every time you click the color chooser button?

      yes

      • What OS/browser/JRE version are you using?

      Windows XP / Firefox 3.6 / JRE_1.6.0_18

      Best regards,

      Alex

      On Jan 22, 2010, at 4:52 AM, Alex XIAO wrote:

      > Dear All,
      >
      > I have some trouble to show the demos, when I click the
      > 'ColorChooserButton', I glimpsed the hole window fill with black color for a
      > second, is this a bug?
      >
      > Thanks!
      >
      > Best Regards,
      >
      > Alex

      1. ApplicationContext_if.diff
        0.6 kB
        Wenguang Liu
      2. ApplicationContext_while.diff
        0.9 kB
        Wenguang Liu
      3. env.txt
        1 kB
        Alex XIAO
      4. pivot.zip
        3.32 MB
        Alex XIAO
      5. PIVOT-390-test.patch
        1 kB
        Todd Volkert
      6. TerraColorChooserSkin.diff
        4 kB
        Wenguang Liu

        Activity

        Hide
        Todd Volkert added a comment -

        Marking to fix in 1.4.1 if we can - this is a serious issue, though I bet finding the cause will be very tricky.

        Show
        Todd Volkert added a comment - Marking to fix in 1.4.1 if we can - this is a serious issue, though I bet finding the cause will be very tricky.
        Hide
        Todd Volkert added a comment -

        Alex, can you try applying the following patch from the SVN trunk, then running the component explorer from the command line to see if you get the black box? The patch should make ColorChooser not paint itself at all, which is obviously not a solution, but it will at least isolate the problem to the paint() methods of TerraColorChooserSkin.

        Show
        Todd Volkert added a comment - Alex, can you try applying the following patch from the SVN trunk, then running the component explorer from the command line to see if you get the black box? The patch should make ColorChooser not paint itself at all, which is obviously not a solution, but it will at least isolate the problem to the paint() methods of TerraColorChooserSkin.
        Hide
        Alex XIAO added a comment -

        when ColorChooser not paint itself, I can't see the black box.

        Show
        Alex XIAO added a comment - when ColorChooser not paint itself, I can't see the black box.
        Hide
        Wenguang Liu added a comment -

        I am not sure if anyone has fixed this already.

        Attached is a small patch/diff, the solution is by doing double buffering.

        Show
        Wenguang Liu added a comment - I am not sure if anyone has fixed this already. Attached is a small patch/diff, the solution is by doing double buffering.
        Hide
        Greg Brown added a comment -

        The odd thing is that we double-buffer everything in the display, so you shouldn't need to do it in TerraColorChooserSkin explicitly.

        I'm curious to know if it has something to do with the use of volatile images for the back buffer. Can you try bypassing the volatile image rendering in ApplicationContext.DisplayHost and just use the buffered image to see if that fixes the problem?

        Show
        Greg Brown added a comment - The odd thing is that we double-buffer everything in the display, so you shouldn't need to do it in TerraColorChooserSkin explicitly. I'm curious to know if it has something to do with the use of volatile images for the back buffer. Can you try bypassing the volatile image rendering in ApplicationContext.DisplayHost and just use the buffered image to see if that fixes the problem?
        Hide
        Wenguang Liu added a comment -

        There is an issue in the function paintVolatileBuffered. The moment we draw the volatile image to the screen, it has already lost its content though we just did the painting.

        The solution is, either we check if its content is still there then we draw to the screen or we leave the work to buffered image (shown in ApplicationContext_if.diff), or we make sure that the content is available before we draw to the screen (ApplicationContext_while.diff).

        Show
        Wenguang Liu added a comment - There is an issue in the function paintVolatileBuffered. The moment we draw the volatile image to the screen, it has already lost its content though we just did the painting. The solution is, either we check if its content is still there then we draw to the screen or we leave the work to buffered image (shown in ApplicationContext_if.diff), or we make sure that the content is available before we draw to the screen (ApplicationContext_while.diff).
        Hide
        Greg Brown added a comment -

        Earlier today I made a change to TerraColorChooserSkin that optimizes its paint behavior. I don't know that this change will have any effect on the issue you are seeing but it may. Is there any chance you can build the latest source code and test this? Your assistance is much appreciated.

        Thanks,
        Greg

        Show
        Greg Brown added a comment - Earlier today I made a change to TerraColorChooserSkin that optimizes its paint behavior. I don't know that this change will have any effect on the issue you are seeing but it may. Is there any chance you can build the latest source code and test this? Your assistance is much appreciated. Thanks, Greg
        Hide
        Duto added a comment -

        Ok I tested with last revision: 998356 and the problem is not fixed, but if I add the -Dsun.java2d.noddraw=true on the vm parameter the flicker disappears

        I make a screencast to show you what is spending :

        http://www.screentoaster.com/watch/stUE5TQkdNRFtXRFpaWV1bV1dS/flicker

        the rendering of this video is not exactly what I see but it's give you a idea

        Show
        Duto added a comment - Ok I tested with last revision: 998356 and the problem is not fixed, but if I add the -Dsun.java2d.noddraw=true on the vm parameter the flicker disappears I make a screencast to show you what is spending : http://www.screentoaster.com/watch/stUE5TQkdNRFtXRFpaWV1bV1dS/flicker the rendering of this video is not exactly what I see but it's give you a idea
        Hide
        Greg Brown added a comment -

        Can you try to bypass the volatile image buffering? See lines 393-397 in ApplicationContext.java:

        // if (!paintVolatileBuffered((Graphics2D)graphics)) {
        if (!paintBuffered((Graphics2D)graphics))

        { paintDisplay((Graphics2D)graphics); }

        // }

        Let me know if this resolves the problem for you.

        Show
        Greg Brown added a comment - Can you try to bypass the volatile image buffering? See lines 393-397 in ApplicationContext.java: // if (!paintVolatileBuffered((Graphics2D)graphics)) { if (!paintBuffered((Graphics2D)graphics)) { paintDisplay((Graphics2D)graphics); } // } Let me know if this resolves the problem for you.
        Hide
        Duto added a comment -

        That's work great with bypass the volatile image buffering : no more flicker

        Show
        Duto added a comment - That's work great with bypass the volatile image buffering : no more flicker
        Hide
        Greg Brown added a comment -

        A system property has been added to support disabling of the volatile image buffer:

        -Dorg.apache.pivot.wtk.disablevolatilebuffer

        When set to true, the volatile buffer will be bypassed and standard image buffering will be used.

        Show
        Greg Brown added a comment - A system property has been added to support disabling of the volatile image buffer: -Dorg.apache.pivot.wtk.disablevolatilebuffer When set to true, the volatile buffer will be bypassed and standard image buffering will be used.
        Hide
        Duto added a comment -

        What the gain of use the paintVolatileBuffered than paintBuffered ? Then we need use -Dorg.apache.pivot.wtk.disablevolatilebuffer=true only when we use ColorChooser on window ?

        Show
        Duto added a comment - What the gain of use the paintVolatileBuffered than paintBuffered ? Then we need use -Dorg.apache.pivot.wtk.disablevolatilebuffer=true only when we use ColorChooser on window ?
        Hide
        Greg Brown added a comment -

        Volatile images are backed directly by video memory and support hardware acceleration on some platforms. Standard buffered images are stored in regular RAM and don't provide any hardware acceleration.

        I would suggest that you disable volatile buffering only if you see this problem. Otherwise, I would leave it enabled for the performance benefit.

        Show
        Greg Brown added a comment - Volatile images are backed directly by video memory and support hardware acceleration on some platforms. Standard buffered images are stored in regular RAM and don't provide any hardware acceleration. I would suggest that you disable volatile buffering only if you see this problem. Otherwise, I would leave it enabled for the performance benefit.

          People

          • Assignee:
            Greg Brown
            Reporter:
            Alex XIAO
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development