Notes which were discussed offline:
- The test uses default pipeline(which can be d3d,ogl,x11,xrender)
- The test also is executed with disabled d3d pipeline(in assumption
that this pipeline is a default).
- On each platform and pipeline the sync operation implements
differently, discussion on macosx-port was when sync on mac was noop.
On 14/01/16 11:43, Ajit Ghaisas wrote:
Hi,
This test does not use D3D or OpenGL pipelines. D3D is specifically
disabled and OpenGL is disabled by default on windows.
This test uses GDI for drawing.
In this case, the call " Toolkit.getDefaultToolkit().sync();" essentially
translates to ::GdiFlush() only.
::GdiFlush() ensures that the drawing starts immediately, but does not
wait till it is completed. (At least this is what my understanding is. Please
correct me if it is wrong)
There is no way to deterministically say that the on-screen rendering is
complete before capturing the screen as done in this test.
(For similar issue - see discussion on
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2014-June/006652.html )
My initial analysis of test failing on slower systems seems incorrect. This
test fails intermittently on high end system as well (x64, i7, 8G RAM, AMD
Radeon HD 7000 ) if run in a loop.
Adding delays after " Toolkit.getDefaultToolkit().sync()" call results in
stable result all the time.
@Phil,
Yes. I will put the final analysis as comments on this bug in JBS.
Regards,
Ajit
-----Original Message-----
From: Philip Race
Sent: Tuesday, January 05, 2016 6:03 AM
To: Sergey Bylokhov
Cc: Ajit Ghaisas; Prasanta Sadhukhan; 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Review request for 8144033 : [TEST_BUG] delays
needed in RenderingToCachedGraphicsTest.java
That is a good question. Is this intermittent failure specific to D3D ?
Why slower systems ? Is sync not doing its job as advertised and this shows up
more on such systems.
I am sure there are times when we need to put in sleep/wait or similar for
timing sensitive issues but they are inherently unreliable too so we need to
understand why it is necessary.
Also such an evaluation needs to go into the bug report not just the email.
-phil.
On 12/31/15, 4:17 AM, Sergey Bylokhov wrote:
Hi, Ajit.
Did you check why Toolkit.getDefaultToolkit().sync(); does not work?
Call to sync should be enough to flush gdi,d3d,ogl pipelines(including
native state) to make visible on the screen the call fillRect.
On 31/12/15 13:41, Ajit Ghaisas wrote:
Hi,
Please review the fix for JDK9.
Webrev:
http://cr.openjdk.java.net/~arapte/ajit/8144033/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8144033
Issue :
The test fails intermittently on slower systems. It passes on
relatively faster systems.
Fix :
1.Robot object is created earlier
2.Added delay after fillRect() calls - the method runTest() is
executed in AWT-EventQueue processing thread hence, we cannot invoke
robot.waitForIdle(). Therefore, delay() method is used.
Regards,
Ajit
--
Best regards, Sergey.
