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

Thu, 19 Feb 2015 05:57:08 -0800 

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

Reply via email to