High Performance Java Swing Animation David Wallace Croft Presented to the Plano Java Users Group Plano, TX Copyright 2004 David Wallace Croft. This work is licensed under the Creative Commons Attribution License.

David Wallace Croft ● Founder and VP, Game Developers Java Users Group ( ● Taught Java game programming at the Institute of Interactive Arts & Engineering at UTD ● Author of "Advanced Java Game Programming" ( ● Software Developer, NIST ATP "Peer-to- Peer Virtual Reality Learning Environments" research grant project, Whoola Inc.

Open Source ● All code presented today is Open Source ● Code documented in detail in the book "Advanced Java Game Programming" ● Source code available for download from ● Public Domain multimedia files also available ● This presentation archived on CroftSoft website

Performance Issues ● Clock resolution ● Hardware acceleration ● Repaint algorithm

Clock Resolution ● Need at least 24 fps for smooth animation ● Period of less than 42 ms ● System.currentTimeMillis() ● Clock resolution 50 to 60 ms on some Windows ● Swing Timer class limited to 20 fps ● Possibly due to clock resolution? ● Thread.sleep() within loop finer control

Animation Loop ● Phase 1: update sprite positions ● Phase 2: repaint sprites at new positions ● Phase 3: delay

LoopGovernor ● Slows animation loop down to desired frame rate ● Too slow = jerky animation ● Too fast = faster than monitor refresh, 100% CPU Do not squander time, for that is the stuff life is made of. -- Benjamin Franklin ● FixedDelayLoopGovernor ● SamplerLoopGovernor ● WindowedLoopGovernor

Hardware Acceleration ● Hardware acceleration for images ● Added to Java in version 1.4 ● Big difference in performance

Definitions ● VRAM = Video Random Access Memory ● Blit = BLT = Block Line Transfer ● Buffer = block of memory for image data ● Pixel = picture element ● Render = calculate and store pixel data ● Primary surface = screen surface ● Back buffer = offscreen image

Class Image ● Package java.awt ● Holds pixel (picture element) data ● Abstract superclass ● Subclasses – BufferedImage – VolatileImage

BufferedImage ● Quick and easy to modify pixel data ● Pixel data not in video memory ● Slow to transfer to video memory ● Blitting ● No hardware acceleration for drawing ops

VolatileImage ● Component.createVolatileImage(width,height ) ● Pixel data in video memory (VRAM) ● Hardware acceleration for drawing ops ● Video memory is volatile ● Screen saver will invalidate ● Must check and reload ● boolean VolatileImage.contentsLost()

CompatibleImage ● GraphicsConfiguration.createCompatibleIma ge() ● Pixel format conversion not needed ● BufferedImage for pixel manipulation ● VolatileImage cache for fast blitting ● Caching mechanism validates volatile memory ● Best for static images since cached ● Caching algorithm out of your control

Transparency ● GraphicsConfiguration.createCompatibleIma ge ( width, height, transparency ) ● Transparency.OPAQUE ● Transparency.BITMASK ● Transparency.TRANSLUCENT ● TRANSLUCENT not accelerated so slow ● Transparency lost when copying to VolatileImage

Translucent Demo ● SpriteDemo fog option ● Performance drops

Scaled BLT ● Graphics.drawImage ( x, y, width, height, null ) ● Slow ● Solution = pre-scale

loadAutomaticImage() ● com.croftsoft.core.awt.image.ImageLib ● Source code review

Repaint Algorithm ● Default algorithm in Swing bad for animation ● Creates union of dirty rectangles ● Slows down when rectangles far apart ● Demonstration using Sprite

RepaintCollector ● Phase 1: Collects repaint requests ● Phase 2: Delivers repaint requests ● Coalesces requests for efficiency ● Default algorithm in Swing bad for animation ● SimpleRepaintCollector ● BooleanRepaintCollector ● CoalescingRepaintCollector

References ● Jeffrey Kesselman, Understanding the AWT Image Types ● Michael Martak, Full-Screen Exclusive Mode API ● Sun, High Performance Graphics ● Sun, The VolatileImage API User Guide

Questions? ● Also ask via book discussion mailing list