This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When drawing code is implemented in an event handler a graphics context is obtained using the getGraphics() method.
Would I be correct in assuming that the results of the drawing operation(s) are stored in this graphics context object, and the reason that the drawing history isn't available to the paint() method when it is called by the GUI thread, is because the paint() method makes calls on an independent graphics context object?
Similarly the update() method takes a graphics context method as a parameter, however the description in the Java API of the repaint() method has nothing to say about repaint() supplying a graphics context object as an argument to update when it calls it.
Can anyone throw some light on what's really going on here?
A Graphics object does NOT store any of the results of drawing, those go to whatever you are drawing on. Look it up, a Graphics object owns things like color and font and a clipping rectangle. The repaint call requests that the JVM repaint a Component or part of a component. When the JVM gets around to it, a special GUI Thread calls update with a Graphics object obtained from the JVM. Generally speaking, the safest thing to do is to do all of your drawing to the screen in the paint method. Bill
Joined: Aug 04, 2000
Hi Bill ! Thanks for your clear explantion of the graphics context object - I think I was just getting a little too complicated about it :-) Kind regards, Adam