[Q] silly newbie wxDC problem

wxPython Users
1

I'm trying (and so far failing) to understand how to use wxDC to create
(OK, this I have solved) and export simple drawings. what I have is
this:

        def OnPaint(self, event):

              dc = wxPaintDC(self)
              dc.BeginDrawing()

              ...

              dc.EndDrawing()

              (thisScreenX, thisScreenY) = self.GetClientSizeTuple()
              self.bitmap = wxEmptyBitmap(thisScreenX, thisScreenY)
              self.memoryCanvas = wxMemoryDC()
              self.memoryCanvas.SelectObject(self.bitmap)

              self.image = wxImageFromBitmap(self.bitmap)
              wxInitAllImageHandlers

              self.image.SaveFile("plopp.gif",wxBITMAP_TYPE_GIF)

a beautiful chart is created and displayed, but the resulting export is
an empty file.

any suggestions? I'm using Windows XP and run the latest versions of
python2.2 and wxPython.

thank you!

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

2

Rolf Marvin Bøe Lindgren wrote:

I'm trying (and so far failing) to understand how to use wxDC to create
(OK, this I have solved) and export simple drawings. what I have is
this:

        def OnPaint(self, event):

              dc = wxPaintDC(self)
              dc.BeginDrawing()

              ...

              dc.EndDrawing()

              (thisScreenX, thisScreenY) = self.GetClientSizeTuple()
              self.bitmap = wxEmptyBitmap(thisScreenX, thisScreenY)
              self.memoryCanvas = wxMemoryDC()
              self.memoryCanvas.SelectObject(self.bitmap)

              self.image = wxImageFromBitmap(self.bitmap)
              wxInitAllImageHandlers

              self.image.SaveFile("plopp.gif",wxBITMAP_TYPE_GIF)

a beautiful chart is created and displayed, but the resulting export is
an empty file.

any suggestions? I'm using Windows XP and run the latest versions of
python2.2 and wxPython.

thank you!

Well, you

(1) create an empty bitmap,
(2) use SelectObject to identify it with a memory DC,
(3) convert it to an image,

and

(4) save the image,

but you never copy anything from the DC on which you painted the graph to the memory DC, so of course the exported file is an empty gif :-). You need to copy from the screen or client DC into the memory DC before step (3):

# get the DC representing the client area of the window (self)
client = wxClientDC(self)

# copy a section with the right width and height from 0, 0 in the client
# DC to 0, 0 in the memory DC
self.memoryCanvas.Blit(0, 0, thisScreenX, thisScreenY, client, 0, 0,
     wxCOPY, true)

Also, I'm not sure you really want to do the capturing of the image in OnPaint, since that means you re-capture and save it any time the window needs to be refreshed. Any access to the wxPaintDC must be done from OnPaint, but you can always use wxClientDC or wxWindowDC to get a copy of this information from another method of the window.

Finally, you probably don't want to store the memory DC permanently, so I would make it a local variable, not a member of the window.

David

3

[David C. Fox]

Well, you

(1) create an empty bitmap,
(2) use SelectObject to identify it with a memory DC,
(3) convert it to an image,

and

(4) save the image,

but you never copy anything from the DC on which you painted the graph
to the memory DC, so of course the exported file is an empty gif
:-). You need to copy from the screen or client DC into the memory DC
before step (3):

hi, and thanks for your reply.

I'm mailing directly to you as I don't suppose this is of general
interest to the list. I'm really struggling to understand this and the
code I've written is largely taken from tutorials.

I create something with

  dc = wxPaintDC(self) ... dc.EndDrawing()

but I never reference the object dc after the drawing is finished. so
is there a place in memory that is just reserved for drawings, so that I
can have only one drawing at one given time? as far as I understand
what I do is copy the bitmap from screen memory.

I think I've followed your suggestion, like this:

        # get the size of the drawing
        (thisScreenX, thisScreenY) = self.GetClientSizeTuple()

        # create an empty bitmap
        self.bitmap = wxEmptyBitmap(thisScreenX,thisScreenY)

        # identify the empty bitmap with a memory DC
        self.memoryCanvas = wxMemoryDC()
        self.memoryCanvas.SelectObject(self.bitmap)

        # get the DC representing the client area of the window (self)
        client = wxClientDC(self)

        # copy a section with the right width and height from 0, 0 in
        # the client DC to 0, 0 in the memory DC
        self.memoryCanvas.Blit(0, 0, thisScreenX, thisScreenY, client, 0,0, wxCOPY, true)

        # convert the bitmap to an image
        self.image = wxImageFromBitmap(self.bitmap)

        # save the image
        self.image.SaveFile("plopp.gif",wxBITMAP_TYPE_GIF)

the result is still an empty file.

any and all help you can provide will be greatly appreciated!

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

4

Rolf Marvin Bøe Lindgren wrote:

[David C. Fox]

> Well, you
> > (1) create an empty bitmap,
> (2) use SelectObject to identify it with a memory DC,
> (3) convert it to an image,
> > and
> > (4) save the image,
> > but you never copy anything from the DC on which you painted the graph
> to the memory DC, so of course the exported file is an empty gif
> :-). You need to copy from the screen or client DC into the memory DC
> before step (3):

hi, and thanks for your reply.

I'm mailing directly to you as I don't suppose this is of general
interest to the list. I'm really struggling to understand this and the
code I've written is largely taken from tutorials.

(Actually, it looks like your reply went back to the list - but that's probably just as well, since I'm not sure I know the answer)

I create something with

  dc = wxPaintDC(self) ... dc.EndDrawing()

but I never reference the object dc after the drawing is finished. so
is there a place in memory that is just reserved for drawings, so that I
can have only one drawing at one given time? as far as I understand

I'm not really an expert on device contexts, but as I understand it, the wxPaintDC is a special purpose DC which is only accessible from within the Paint event handler (usually called OnPaint). So it is perfectly normal not to refer to the paint DC again once you've called EndDrawing.

If you want to create a drawing off-screen, you use a wxMemoryDC, select a bitmap into it, and then draw into the memory DC. Then, to display that drawing, you can use the Blit method to copy it into the PaintDC in OnPaint.

> can have only one drawing at one given time? as far as I understand

what I do is copy the bitmap from screen memory.

I think I've followed your suggestion, like this:

        # get the size of the drawing
        (thisScreenX, thisScreenY) = self.GetClientSizeTuple()

        # create an empty bitmap
        self.bitmap = wxEmptyBitmap(thisScreenX,thisScreenY)

        # identify the empty bitmap with a memory DC
        self.memoryCanvas = wxMemoryDC()
        self.memoryCanvas.SelectObject(self.bitmap)

        # get the DC representing the client area of the window (self)
        client = wxClientDC(self)

        # copy a section with the right width and height from 0, 0 in
        # the client DC to 0, 0 in the memory DC
        self.memoryCanvas.Blit(0, 0, thisScreenX, thisScreenY, client, 0,0, wxCOPY, true)

        # convert the bitmap to an image
        self.image = wxImageFromBitmap(self.bitmap)

        # save the image
        self.image.SaveFile("plopp.gif",wxBITMAP_TYPE_GIF)

the result is still an empty file.

Oh, wait, I think I remember that you can't save GIFs (they can't include code to save GIFs in wxWindows because of the company that has a patent on the GIF compression algorithm, I think). Try JPEG or PNG.

David

5

[David C. Fox]

Oh, wait, I think I remember that you can't save GIFs (they can't
include code to save GIFs in wxWindows because of the company that has
a patent on the GIF compression algorithm, I think). Try JPEG or PNG.

tell you what, you're absolutely right. it's a strange world. it works
now.

thanks!

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

6

"Rolf Marvin Bøe Lindgren" wrote:

> Oh, wait, I think I remember that you can't save GIFs (they can't

tell you what, you're absolutely right. it's a strange world. it works
now.

You've solved your immediate problem, but you probably should re-factor
your code anyway. It looks like what you want to do is do all your
drawing to an off screen bitmap, using wxMemoryDC, and then just use a
DC.DrawBitmap or DC.Blit() in your OnPaint handler. If you do that,
you'll get fast screen refreshes, and always have the current image
around for saving to a file.

By the way, don't keep your MemoryDC around, just keep the bitmap.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

7

Despite Robin's warnings against keeping a wxMemoryDC around, I have never
run into a problem with doing so, even with multiple apps running, each with
one or more wxMemoryDCs kept around for the PythonCard BitmapCanvas class.
If there is a specific scarce resource condition to watch out for on
Win9x/ME or another platform I would like to know what the problem case is
before saying, don't do it.

It is really inconvenient to have to use a wxBufferedDC every time you want
to do a single wxDC draw operation. You have to create the dc, setup the pen
and brush, etc. even for one DrawLine call. So using a wxMemoryDC and
letting it keep the state is easier.

A bit off-topic...
I would still like to have a C++ mixin that would provide all the wxDC
methods for an offscreen-bitmap that you could use with a wxWindow. It would
wrap all the wxDC methods, manage the pen and brush state, provide automatic
blits, allowing auto-refreshing to be turned off for batch draw operations,
etc. If that used wxBufferedDC but hid the fact that would be fine. I just
want to be able to do:

w = wxBitmapWindow(...)
w.DrawLine(...)

and have that show up on screen. I can do that with PythonCard, but it would
be nice to have in wxPython and optimized.

ka

···

-----Original Message-----
From: Chris Barker

"Rolf Marvin Bøe Lindgren" wrote:
> > Oh, wait, I think I remember that you can't save GIFs (they can't

> tell you what, you're absolutely right. it's a strange world. it works
> now.

You've solved your immediate problem, but you probably should re-factor
your code anyway. It looks like what you want to do is do all your
drawing to an off screen bitmap, using wxMemoryDC, and then just use a
DC.DrawBitmap or DC.Blit() in your OnPaint handler. If you do that,
you'll get fast screen refreshes, and always have the current image
around for saving to a file.

By the way, don't keep your MemoryDC around, just keep the bitmap.

8

Kevin Altis wrote:

Despite Robin's warnings against keeping a wxMemoryDC around, I have never
run into a problem with doing so, even with multiple apps running, each with
one or more wxMemoryDCs kept around for the PythonCard BitmapCanvas class.

As it happens, neither have I, but I run mostly wxGTK. I have learned to
trust Robin's opinion on such matters, however.

It is really inconvenient to have to use a wxBufferedDC every time you want
to do a single wxDC draw operation. You have to create the dc, setup the pen
and brush, etc. even for one DrawLine call. So using a wxMemoryDC and
letting it keep the state is easier.

Yes, that is a little cleaner, but I've found that I end up writing at
least a little framework around all my drawing stuff anyway, so it's not
such a big deal.

I would still like to have a C++ mixin that would provide all the wxDC
methods for an offscreen-bitmap that you could use with a wxWindow. It would
wrap all the wxDC methods, manage the pen and brush state, provide automatic
blits, allowing auto-refreshing to be turned off for batch draw operations,
etc. If that used wxBufferedDC but hid the fact that would be fine. I just
want to be able to do:

w = wxBitmapWindow(...)
w.DrawLine(...)

and have that show up on screen. I can do that with PythonCard, but it would
be nice to have in wxPython and optimized.

I agree that such a thing is a great idea. Have yopu done any profiling
that indicates that putting it in C++ would make it notably faster? The
only performance gain that I see is for an object canvas, where all the
objects stored could be looped through at C++ speed, and DrawXXXList
gets close to solving that problem. There may be others I'm not aware
of, however.

-CHB

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

9

I think this problem is limited to Win9x, which had a static size for
certain resources (and this was a shared global resource for all
applications, IIRC) and holding onto them could cause problems (out of
resources warnings when there was a ton of memory left). My memory of
this is rather vague, but I think that's where the warnings come from.

···

On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:

> -----Original Message-----
> From: Chris Barker
>
> "Rolf Marvin Bøe Lindgren" wrote:
> > > Oh, wait, I think I remember that you can't save GIFs (they can't
>
> > tell you what, you're absolutely right. it's a strange world. it works
> > now.
>
> You've solved your immediate problem, but you probably should re-factor
> your code anyway. It looks like what you want to do is do all your
> drawing to an off screen bitmap, using wxMemoryDC, and then just use a
> DC.DrawBitmap or DC.Blit() in your OnPaint handler. If you do that,
> you'll get fast screen refreshes, and always have the current image
> around for saving to a file.
>
> By the way, don't keep your MemoryDC around, just keep the bitmap.

Despite Robin's warnings against keeping a wxMemoryDC around, I have never
run into a problem with doing so, even with multiple apps running, each with
one or more wxMemoryDCs kept around for the PythonCard BitmapCanvas class.
If there is a specific scarce resource condition to watch out for on
Win9x/ME or another platform I would like to know what the problem case is
before saying, don't do it.

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

10

Aha. Here it is:

I can hear Bill now: "who'd ever need more than 64K of resources?"

···

On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:

Despite Robin's warnings against keeping a wxMemoryDC around, I have never
run into a problem with doing so, even with multiple apps running, each with
one or more wxMemoryDCs kept around for the PythonCard BitmapCanvas class.
If there is a specific scarce resource condition to watch out for on
Win9x/ME or another platform I would like to know what the problem case is
before saying, don't do it.

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

11

Cliff Wells wrote:

> Despite Robin's warnings against keeping a wxMemoryDC around
Aha. Here it is:

http://aroundcny.com/technofile/texts/tec031200.html

OK, does this mean that if I don't care if my app runs well on Win <
2000, I can keep a bunch of wxMemoryDCs around? (Now that I've recently
refactored the FloatCanvas to not keep them around...)

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

12

Excellent. But that 64K does not include the size of the wxMemoryDC, it must
be certain aspects associated with it such as the pen and brush. If it
included the wxMemoryDC you wouldn't be able to create a wxMemoryDC of even
100x220x24 bits.

64 * 1024 (bytes) / 3 (bytes per pixel) / 100 (pixels horizontal)

is just over 218; assuming my calculations are correct. So it is something
else about the wxMemoryDC use of "resources" and we would need to know what,
how much, how to check whether the resource was actually freed, even at
program exit where you might assume it was and it might not be.

ka

···

-----Original Message-----
From: Cliff Wells

On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:

> Despite Robin's warnings against keeping a wxMemoryDC around, I
have never
> run into a problem with doing so, even with multiple apps
running, each with
> one or more wxMemoryDCs kept around for the PythonCard
BitmapCanvas class.
> If there is a specific scarce resource condition to watch out for on
> Win9x/ME or another platform I would like to know what the
problem case is
> before saying, don't do it.

Aha. Here it is:

http://aroundcny.com/technofile/texts/tec031200.html

I can hear Bill now: "who'd ever need more than 64K of resources?"

13

Clearly not. I expect it's merely the "handle" for that DC that takes
up space in that 64K. However, when you consider that this is 64K
*system wide*, and the possible number of resource handles that each
application (and windows itself) must need, you can see how it might
get used up rather quickly. Also, it seems possible that each handle is
not merely a pointer (32 bits) but probably a small structure, so there
is probably a limit of far less than 64K resources at any given moment.

···

On Mon, 2003-01-13 at 12:58, Kevin Altis wrote:

> -----Original Message-----
> From: Cliff Wells
>
> On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:
>
> > Despite Robin's warnings against keeping a wxMemoryDC around, I
> have never
> > run into a problem with doing so, even with multiple apps
> running, each with
> > one or more wxMemoryDCs kept around for the PythonCard
> BitmapCanvas class.
> > If there is a specific scarce resource condition to watch out for on
> > Win9x/ME or another platform I would like to know what the
> problem case is
> > before saying, don't do it.
>
> Aha. Here it is:
>
> http://aroundcny.com/technofile/texts/tec031200.html
>
> I can hear Bill now: "who'd ever need more than 64K of resources?"

Excellent. But that 64K does not include the size of the wxMemoryDC, it must
be certain aspects associated with it such as the pen and brush. If it
included the wxMemoryDC you wouldn't be able to create a wxMemoryDC of even
100x220x24 bits.

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

14

YARTL: Yet Another Reason To Use Linux :wink:

···

-----Original Message-----
From: Cliff Wells [mailto:LogiplexSoftware@earthlink.net]
Sent: Monday, January 13, 2003 3:45 PM
To: wxPython-users@lists.wxwindows.org
Subject: RE: [wxPython-users] [Q] silly newbie wxDC problem

On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:

Despite Robin's warnings against keeping a wxMemoryDC around, I have never
run into a problem with doing so, even with multiple apps running, each

with

one or more wxMemoryDCs kept around for the PythonCard BitmapCanvas class.
If there is a specific scarce resource condition to watch out for on
Win9x/ME or another platform I would like to know what the problem case is
before saying, don't do it.

Aha. Here it is:

I can hear Bill now: "who'd ever need more than 64K of resources?"

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

15

Agreed. So I argue that if you are going to need a wxMemoryDC for a long
running app, say in association with a double-buffered window, it would be
best to grab that resource when the program starts and keep it until you no
longer need it. That wxMemoryDC is going to get used every time the window
needs any portion redrawn as well as for any content updates. If you weren't
able to grab it in the middle of running the program, say to update on a
paint event, that would be bad news. If your system resources are already
dangerously low when you start up the app on Win9x then at least you can
fail gracefully when you try and allocate at app startup.

If instead you had only a temporary need for a wxMemoryDC at various
optional stages while the app is run and it is going to be okay to fail to
get the resource then by all means go ahead and create and destroy a
wxMemoryDC or use a wxBufferedDC in that context. Remember that Python GC is
not going to guarantee that the object is ever freed, so you take your
chances and could potentially use up more resources than just grabbing the
resource at program start and keeping it. You could force the GC calls once
you're done with an object, but that would be a pain.

wxBufferedDC uses a wxMemoryDC or is equivelant for these discussions,
right?

For the real operating systems: Win NT/2K/XP, Linux, Mac OS X, either
approach will work.

ka

···

-----Original Message-----
From: Cliff Wells

On Mon, 2003-01-13 at 12:58, Kevin Altis wrote:
> > -----Original Message-----
> > From: Cliff Wells
> >
> > On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:
> >
> > > Despite Robin's warnings against keeping a wxMemoryDC around, I
> > have never
> > > run into a problem with doing so, even with multiple apps
> > running, each with
> > > one or more wxMemoryDCs kept around for the PythonCard
> > BitmapCanvas class.
> > > If there is a specific scarce resource condition to watch out for on
> > > Win9x/ME or another platform I would like to know what the
> > problem case is
> > > before saying, don't do it.
> >
> > Aha. Here it is:
> >
> > http://aroundcny.com/technofile/texts/tec031200.html
> >
> > I can hear Bill now: "who'd ever need more than 64K of resources?"
>
> Excellent. But that 64K does not include the size of the
wxMemoryDC, it must
> be certain aspects associated with it such as the pen and brush. If it
> included the wxMemoryDC you wouldn't be able to create a
wxMemoryDC of even
> 100x220x24 bits.

Clearly not. I expect it's merely the "handle" for that DC that takes
up space in that 64K. However, when you consider that this is 64K
*system wide*, and the possible number of resource handles that each
application (and windows itself) must need, you can see how it might
get used up rather quickly. Also, it seems possible that each handle is
not merely a pointer (32 bits) but probably a small structure, so there
is probably a limit of far less than 64K resources at any given moment.

16

Kevin Altis wrote:

Agreed. So I argue that if you are going to need a wxMemoryDC for a long
running app, say in association with a double-buffered window, it would be
best to grab that resource when the program starts and keep it until you no
longer need it. That wxMemoryDC is going to get used every time the window
needs any portion redrawn as well as for any content updates. If you weren't
able to grab it in the middle of running the program, say to update on a
paint event, that would be bad news. If your system resources are already
dangerously low when you start up the app on Win9x then at least you can
fail gracefully when you try and allocate at app startup.

From the note that Cliff linked to, it sounds like your system will

crash..not exactly failing gracefully. I think the issue is that you may
have multiple apps running (if you don't resource limitations are
probably not sucha big deal), so you really don't want to tie up
resources that another app may need, while yours is sitting idle in the
background. It does seem with limited resources, only using something
when you really need it is a good rule of thumb.

The best alternative is to use a Real operating system, which I may be
just as happy to require for my apps. Of course, others may well not
have that option.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

17

Hi all,

I just noticed in the DrawXXWList demo that it is set up with a cach for
pens: a dictionary, indexed by a tuple of the pens properties, so that
multiple copies of the same wxPen are not created.

I thought this was odd, because I understood that in recent versions of
wxPython, this kind of caching was done behind the scenes in wxWindows,
by maintianing wxThePenList or something like that.

Does it make sense to cache wxPens and wxBrushes in this manner?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

18

Hi all,

I just noticed in the DrawXXWList demo that it is set up with a cach for
pens: a dictionary, indexed by a tuple of the pens properties, so that
multiple copies of the same wxPen are not created.

I thought this was odd, because I understood that in recent versions of
wxPython, this kind of caching was done behind the scenes in wxWindows,
by maintianing wxThePenList or something like that.

Not even that recent. It's been like that for at least 3 years.

Does it make sense to cache wxPens and wxBrushes in this manner?

Dunno. Perhaps from a Python POV, in order to avoid making a lot of
unnecessary calls into the wxWindows libraries. Since the list is
statically maintained by wxWindows anyway, I don't suppose Python
keeping an extra reference to them matters much.

···

On Mon, 2003-01-13 at 13:54, Chris Barker wrote:

--
Cliff Wells <clifford.wells@attbi.com>

19

Kevin Altis wrote:

···

-----Original Message-----
From: Cliff Wells

On Mon, 2003-01-13 at 12:01, Kevin Altis wrote:

Despite Robin's warnings against keeping a wxMemoryDC around, I

have never

run into a problem with doing so, even with multiple apps

running, each with

one or more wxMemoryDCs kept around for the PythonCard

BitmapCanvas class.

If there is a specific scarce resource condition to watch out for on
Win9x/ME or another platform I would like to know what the

problem case is

before saying, don't do it.

Aha. Here it is:

http://aroundcny.com/technofile/texts/tec031200.html

I can hear Bill now: "who'd ever need more than 64K of resources?"

Excellent. But that 64K does not include the size of the wxMemoryDC, it must
be certain aspects associated with it such as the pen and brush.

It's all the resource "handles." Every GDI object has a handle, DCs, pens, brushes, bitmaps, fonts, icons, etc. All are considered a "scarce" resource and until win9x/Me totally dies and does not exist on any target user's machine then it is a good idea to conserve the scarce resources when you can and only create them when you need them and let them go as soon as possible.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

20

Kevin Altis wrote:

wxBufferedDC uses a wxMemoryDC or is equivelant for these discussions,
right?

Yes, it derives from wxMemoryDC.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!