[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] Review request for 8144033 : [TEST_BUG] delays needed in RenderingToCachedGraph
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2016-01-14 17:14:10
Message-ID: 5697D762.70605 () oracle ! com
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]