Hi Sergey,
> Is there a reason why AWT doesn't explicitly flush and whythe >> flush-after-blit approach was chosen? >> > If a sync will be implemented in a Swing, then will be necessary to add a > sync to all places where we paint an images to the screen, and this is > equivalent of current solution, no? Instead of thinking on the j2d level (blits), wouldn't it be enough to flush after handling of events that can possibly issue paint-operations to screen? This would also have the advantage to have contents flushed to screen even for the non-doublebuffered case (if I modify the example to use a Frame instead a double-buffered JFrame I get stutter with all j2d pipelines). The reason why I am not very happy with the current way is because: 1. It doesn't cover all cases, like non-doublebuffered frames. 2. It can lead to excessive sync'ing. Imagine an AWT based J2D based game which renderes hundreds or even thousands of sprites directly to screen. While this might be acceptable for OGL/D3D, it for sure is a no-go for Xrender over network. 3. It is in my opinion at the wrong layer of abstraction, leading to semantics/heuristics encoded into J2D which don't belong there. Actually AWT knows when contents should be flushed to screen. J2D currently flushes after *every* Blit, regardless wether it is required or not. Also, it doesn't flush for other primitives like rects or lines making it's behaviour inconsistent. Best regards, Clemens
