The main Device Context is called "wxDC."

You can't instantiate wxDC directly; It's just there for interface specification, and documentation purposes.

Instead, you instantiate a subclass of wxDC.

 * [[http://wxpython.org/docs/api/wx.DC-class.html|wxPython wxDC documentation]]
 * [[http://wxwidgets.org/manuals/2.6.1/wx_wxdc.html#wxdc|wxWidgets wxDC documentation]]

== EVT_PAINT ==

Something important to know: If your device context involves drawing to the screen, it matters whether you are in the middle of handling an EVT_PAINT event, or not. (EVT_PAINT events are sent by the system when the gui is being redrawn: e.g. window dragging)

You need one DC while handling an EVT_PAINT handler, and another when you're not.

Within EVT_PAINT, you use a {{{wx.PaintDC}}} object. In fact, you have to. See [[http://www.wxpython.org/docs/api/wx.PaintEvent-class.html|PaintEvent]].

Outside, you use a {{{wx.WindowDC}}}.

If you want to draw on a buffer first, then you choose between {{{wx.BufferedPaintDC}}} (within an EVT_PAINT), or, {{{wx.BufferedDC}}} (outside EVT_PAINT.)

 * [[http://wxpython.org/docs/api/wx.ClientDC-class.html|wx.ClientDC]] -- writing on the screen, '''not''' in EVT_PAINT 
 * [[http://wxpython.org/docs/api/wx.PaintDC-class.html|wx.PaintDC]] -- writing on the screen, for use within EVT_PAINT handler
 
== Buffered Device Contexts ==

Some device contexts are buffered, and have this curious property: They draw to the screen when the device context is deleted.

That is, when the device context goes out of scope, ''then'' it is suddenly copied to the screen, before dying.

 * [[http://wxpython.org/docs/api/wx.BufferedDC-class.html|wx.BufferedDC]] -- buffered, '''not''' in EVT_PAINT
 * [[http://wxpython.org/docs/api/wx.BufferedPaintDC-class.html|wx.BufferedPaintDC]] -- buffered, for use within EVT_PAINT handler