[OpenJDK 2D-Dev] Review request for 8144033 : [TEST_BUG] delays needed in RenderingToCachedGraphicsTest.java

[Sergey Bylokhov]

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 at 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.