[OpenJDK 2D-Dev] Review Request for bug (JDK-8039345) Strange behaviour of per-pixel translucency on linux

Thu Feb 19 15:25:14 UTC 2015

> Could you explain bit more? not sure I understand what you wanted me 
> to do? 

In current version of test all swing methods(including JFrame 
constructor) are invoked on the main thread,
this can lead to some vague issues. To avoid such issues they should be 
wrapped with SwingUtilities.invokeAndWait()
or with SwingUtilities.invokeLater(). For example in bug6505523.java[0] 
all swing related calls are placed
on EDT, all robot related are placed on the main thread.
You can grep through tests directory to find other usages.

BTW, there are many unused imports in the test and ComponentResizeTest 
extends JFrame for no reason.

[0] 
http://hg.openjdk.java.net/jdk9/client/jdk/file/c867d4d46b58/test/javax/swing/JTree/6505523/bug6505523.java

Thanks,

Alexander.

On 02/19/2015 04:56 PM, prasanta sadhukhan wrote:
> Hi ALexander.
> On 2/19/2015 6:55 PM, Alexander Zvegintsev wrote:
>> Hello Prasanta,
>>
>> I have a couple of comments regarding the test:
>>
>> We should invoke swing methods on EDT [0].
>>
> Could you explain bit more? not sure I understand what you wanted me 
> to do?
>> I think that this test might be improved by showing an instruction
>> window before test begins. Instruction should explain what is about
>> to happen, what behavior is correct. Tester will get a better 
>> understanding
>> of what to expect from the test, he will not miss the test start in case
>> if he gets distracted.
>>
> Ok. will do.
>
> Regards
> Prasanta
>> [0] 
>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 02/17/2015 03:43 PM, prasanta sadhukhan wrote:
>>> A reg. testcase is added to the webrev
>>> http://cr.openjdk.java.net/~serb/prasanta/8039345/webrev.01/
>>> Regarding the transparency parameter, I decided not to remove it as 
>>> of now for firstly, it has no bearing on this bug as per our testing 
>>> and secondly, it might be needed in future.
>>>
>>> Regards
>>> Prasanta
>>> On 2/14/2015 1:33 AM, Phil Race wrote:
>>>> I tried again and this time it works for me so it seems like it was 
>>>> a false alarm.
>>>> If the transparency parameter is really un-needed then you can 
>>>> remove it but
>>>> you should take a look to see if it appears to be an oversight that 
>>>> it is not used
>>>> A reg. test for this fix is desirable.
>>>>
>>>> -phil.
>>>>
>>>> On 02/13/2015 04:08 AM, prasanta sadhukhan wrote:
>>>>> I tried my fix on latest ubuntu14.04 and it seems to work for me, 
>>>>> the checkbox and button gets painted without any trails and 
>>>>> without any exception.
>>>>> Also, regarding Clemens suggestion that "Transparency.OPAQUE is 
>>>>> also passed to the super constructor of XRWindowSurfaceData" it is 
>>>>> observed that the "transparancy" parameter is not used in the 
>>>>> super constructor so it shouldn't have any effect on this 
>>>>> particular bug, maybe we can remove the parameter from the super 
>>>>> constructor for its lack of use.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 2/10/2015 3:34 AM, Phil Race wrote:
>>>>>> I tried this on Ubuntu (13.04) with the test case in the bug (BTW 
>>>>>> there should be a regression test
>>>>>> along with this fix) and I get a nasty exception (as below) and 
>>>>>> the checkbox and button don't get painted.
>>>>>>
>>>>>> Exception in thread "AWT-EventQueue-0" 
>>>>>> java.lang.NullPointerException
>>>>>>     at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:196)
>>>>>>     at sun.java2d.SunGraphics2D.copyImage(SunGraphics2D.java:3232)
>>>>>>     at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3396)
>>>>>>     at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3345)
>>>>>>     at 
>>>>>> java.awt.Component$BltBufferStrategy.showSubRegion(Component.java:4472) 
>>>>>>
>>>>>>     at 
>>>>>> java.awt.Component$BltSubRegionBufferStrategy.show(Component.java:4597) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.BufferStrategyPaintManager.flushAccumulatedRegion(BufferStrategyPaintManager.java:371)
>>>>>>     at 
>>>>>> javax.swing.BufferStrategyPaintManager.endPaint(BufferStrategyPaintManager.java:333)
>>>>>>     at javax.swing.RepaintManager.endPaint(RepaintManager.java:1387)
>>>>>>     at javax.swing.JComponent.paint(JComponent.java:1041)
>>>>>>     at 
>>>>>> java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) 
>>>>>>
>>>>>>     at 
>>>>>> sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) 
>>>>>>
>>>>>>     at 
>>>>>> sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) 
>>>>>>
>>>>>>     at java.awt.Container.paint(Container.java:1997)
>>>>>>     at java.awt.Window.paint(Window.java:3929)
>>>>>>     at javax.swing.RepaintManager$4.run(RepaintManager.java:851)
>>>>>>     at javax.swing.RepaintManager$4.run(RepaintManager.java:823)
>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>     at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>>>>>>     at 
>>>>>> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:823) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:798) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:747) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.RepaintManager.access$1300(RepaintManager.java:65)
>>>>>>     at 
>>>>>> javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1751)
>>>>>>     at 
>>>>>> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>>>>>>     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:759)
>>>>>>     at java.awt.EventQueue.access$500(EventQueue.java:97)
>>>>>>     at java.awt.EventQueue$3.run(EventQueue.java:712)
>>>>>>     at java.awt.EventQueue$3.run(EventQueue.java:706)
>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>     at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>>>>>>     at java.awt.EventQueue.dispatchEvent(EventQueue.java:729)
>>>>>>     at 
>>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:190)
>>>>>>     at 
>>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:115)
>>>>>>     at 
>>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:104)
>>>>>>     at 
>>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:100) 
>>>>>>
>>>>>>     at 
>>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:92)
>>>>>>     at java.awt.EventDispatchThread.run(EventDispatchThread.java:81)
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 02/05/2015 03:31 AM, prasanta sadhukhan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review a fix for this issue:
>>>>>>> 8039345 Strange behaviour of per-pixel translucency on linux
>>>>>>>
>>>>>>> Bug description: https://bugs.openjdk.java.net/browse/JDK-8039345
>>>>>>> webrev: 
>>>>>>> http://cr.openjdk.java.net/~serb/prasanta/8039345/webrev.00/
>>>>>>>
>>>>>>> Note: A wrong (PictStandardRGB24) picture format was used for 
>>>>>>> xrendering even for surface having alpha support thereby 
>>>>>>> neglecting the alpha transparency. It should be using 
>>>>>>> PictStandardARGB32 or TRANSLUCENT picture format for correct 
>>>>>>> alpha support in xrendered surface.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>>
>>>>
>>>
>>
>