• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What's really going on with the graphics context?

 
Adam Ratcliffe
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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?


Kind regards,

Adam Ratcliffe
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Adam Ratcliffe
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic