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 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