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

[Ajit Ghaisas]

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