Rotate a dc?

Is there a easy way to rotate a wxDC??
or do I have to calculate new x, y??

Stefan Holmgren wrote:

Is there a easy way to rotate a wxDC??
or do I have to calculate new x, y??

There's no auto way that I know of, you'll have to do the calculations
yourself. Another way would be to draw to a bitmap with a wxMemoryDC,
then turn it into an image, then rotate that.

If you give us more info about what you need to do, someone mihgt have
some better ideas.

-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

Hi all,

Some of you may recall that a problem was found with the double buffered
window demo that I put in the Wiki
(http://wiki.wxpython.org/index.cgi/DoubleBufferedDrawing).

The problem is that I was using wxClientDC.DrawBitmap() to update the
screen when the buffer changed outside of an OnPaint or OnSize event. If
I write the code like this:

wxClientDC(self).DrawBitmap(self._Buffer,0,0)

The screen didn't update. I posted a question here, and Robin discovered
that if you re-wrote that line as:

dc = wxClientDC(self)
dc.DrawBitmap(self._Buffer,0,0)

(self._Buffer is a bitmap of what should be on the screen)

It worked, which is very odd, because according to how Python works,
those should be equivalent. I thought the matter was closed. However, in
a more complex app, I found that the screen was sometimes not updating
itself, even if I used the latter construction.

I've finally found a solution that appears to be robust:

wxClientDC(self).Blit(0, 0, self.Width, self.Height, dc, 0, 0)

Using a Blit() rather than DrawBitmap() seems to be more reliable. It's
less clean code (I wish all those arguments had logical defaults!), and
the other downside is that you need to have a DC around, rather than
just the Bitmap. As a matter of fact, in the OnPaint event, I would have
to create a wxMemoryDC, just to blit from it. For some reason, however,
the DrawBitmap() call works in the OnPaint event. Go figure.

By the way, wxClientDC(self).DrawBitmap(self._Buffer,0,0) works just
fine on wxGTK, so this is a bug in wxMSW. I've found a work around, and
will be updating the Wiki to reflect it. I'm posting here to see if this
warrants a bug report, and to see if anyone else has seen this problem,
or has any insight into what's going on.

-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

Chris Barker wrote:

Hi all,

Some of you may recall that a problem was found with the double buffered
window demo that I put in the Wiki
(http://wiki.wxpython.org/index.cgi/DoubleBufferedDrawing).

The problem is that I was using wxClientDC.DrawBitmap() to update the
screen when the buffer changed outside of an OnPaint or OnSize event. If
I write the code like this:

wxClientDC(self).DrawBitmap(self._Buffer,0,0)

The screen didn't update. I posted a question here, and Robin discovered
that if you re-wrote that line as:

dc = wxClientDC(self)
dc.DrawBitmap(self._Buffer,0,0)

(self._Buffer is a bitmap of what should be on the screen)

It worked, which is very odd, because according to how Python works,
those should be equivalent. I thought the matter was closed. However, in
a more complex app, I found that the screen was sometimes not updating
itself, even if I used the latter construction.

I've finally found a solution that appears to be robust:

wxClientDC(self).Blit(0, 0, self.Width, self.Height, dc, 0, 0)

Using a Blit() rather than DrawBitmap() seems to be more reliable. It's
less clean code (I wish all those arguments had logical defaults!), and
the other downside is that you need to have a DC around, rather than
just the Bitmap. As a matter of fact, in the OnPaint event, I would have
to create a wxMemoryDC, just to blit from it. For some reason, however,
the DrawBitmap() call works in the OnPaint event. Go figure.

By the way, wxClientDC(self).DrawBitmap(self._Buffer,0,0) works just
fine on wxGTK, so this is a bug in wxMSW. I've found a work around, and
will be updating the Wiki to reflect it. I'm posting here to see if this
warrants a bug report, and to see if anyone else has seen this problem,
or has any insight into what's going on.

It may be a bug but I'd like to chase it down further. If you can come up with a simple sample and image that fails consistently with DrawBitmap using two steps then I'd appreciate it.

···

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

Robin Dunn wrote:

It may be a bug but I'd like to chase it down further. If you can come
up with a simple sample and image that fails consistently with
DrawBitmap using two steps then I'd appreciate it.

I'll see what I can do. The problem manifested itself when I was writing
code to play a movie of sorts, updateing the screen as fast as possible.
I suspect it has something to do with how quickly the wxClientDC is
destroyed, and/or how quickly a new one is created. THis surprises me,
as I didn't think Windows did any of this kind of thing asychronisly,
but what do I know? (not much).

Anyway, the fast that it consistantly doesn't work with:

wxClientDC().DrawBitmap(stuff...)

Implies that there is a bug, because that should work!, but it's so easy
to work around that it's worth findout out if it's really a problem when
called in two steps. I'll try adding some kind of animation to my
DoubleBufferedWindow, and see if that breaks it. I'm not sure when I can
get to it, by plate is very full this week.

-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