Browse Prior Art Database

Performance Enhancement for Graphic Rendering in Java

IP.com Disclosure Number: IPCOM000123871D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 2 page(s) / 73K

Publishing Venue

IBM

Related People

Gordon, JM: AUTHOR [+3]

Abstract

Disclosed herein is a method for increasing the efficiency of Java code which renders graphics without being passed a Graphics context. Use of this method translates directly into increased code performance proportional to the number of times the rendering method is called.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Performance Enhancement for Graphic Rendering in Java

   Disclosed herein is a method for increasing the efficiency
of Java code which renders graphics without being passed a Graphics
context.  Use of this method translates directly into increased code
performance proportional to the number of times the rendering method
is called.

   Rendering Graphics in Java requires a Graphics
object.  This Graphics object is, in fact, the context to which the
program intends to render the graphics.  Normally, this Graphics
object is provided to the painting code by the system; however, there
is at least one case where it is not.  That case is when the program
itself generates the paint request.  That is, the program wishes to
render to the screen without being asked by the system.
Traditionally, this is done by calling repaint, which then fetches
the Graphics object through a getGraphics() call, and then calls
update() passing the graphics context, which in turn calls paint()
again passing the context.  Those skilled in the art would optimize
or optimize out the update() method; however, the fetch of the
Graphics object remains.  Our tracing has shown this fetch to be an
expensive call.  Tracing measurements made show this fetch can
account for as much as 80% of the total time spent in optimized
rendering code.  This is significant, more so in a program which is
continuously painting something such as an animation (which might be
called as often as 10 to 30 times per second).

   The idea disclosed here is an optimisation for the case
where the program wishes to paint without being asked, eg. an
animation.  In 99% of the cases, this graphics context does NOT in
fact change, and can therefore be "cached" for repeated use (saving
the overhead of fetching it).  For the 1% where this context does
change (the window has been resized, moved, partially obscured,
etc.), the cached context must be invalidated or the result will be
painting to the wrong area.

   There are...