Hi,
I'm running into a problem on OS X Tiger where the text keeps overwriting itself instead being cleared before written again. It appears to be a bug... I've attached a sample program to demonstrate this. Can someone test this on OS X (Tiger preferably) to see if you get the same problem? -- just drag the mouse to increment the numbers. This run fine on Windows.
Note, Tiger comes with wxPython 2.5.3.1, and that's what we're still running. I've checked the "recent changes" to see if this might have been fixed but doesn't appear to be.
Bob
drawtext.py (1.31 KB)
Bob Klimek wrote:
I'm running into a problem on OS X Tiger where the text keeps
overwriting itself instead being cleared before written again. It
appears to be a bug... I've attached a sample program to demonstrate
this. Can someone test this on OS X (Tiger preferably) to see if you
get the same problem? -- just drag the mouse to increment the numbers.
This run fine on Windows.
Note, Tiger comes with wxPython 2.5.3.1, and that's what we're still
running. I've checked the "recent changes" to see if this might have
been fixed but doesn't appear to be.
Bob, I've run your code on Tiger with wxPython - both 2.6.1.0 and
2.6.1.1-pre20050615 and see the same problem. But if you explicitly do a
dc.SetBackground() before clearing the DC it seems to do the trick:
def OnPaint(self, event):
dc = wx.PaintDC(self)
self.drawText(dc)
event.Skip()
def OnMouseMove(self, event):
if event.Dragging():
self.count = self.count + 1
dc = wx.ClientDC(self)
self.drawText(dc)
def drawText(self, dc):
dc.SetBackground(wx.Brush("white"))
dc.Clear()
dc.SetFont(self.font)
txt = "count: " + str(self.count)
dc.DrawText(txt, 20, 20)
Although it has no effect on the immediate problem, the PaintDC in your
original code is never used - drawText always creates a ClientDC.
Regards,
David Hughes
Forestfield Software
www.foresoft.co.uk
David Hughes wrote:
Bob Klimek wrote:
I'm running into a problem on OS X Tiger where the text keeps overwriting itself instead being cleared before written again. It appears to be a bug... I've attached a sample program to demonstrate this. Can someone test this on OS X (Tiger preferably) to see if you get the same problem? -- just drag the mouse to increment the numbers. This run fine on Windows.
Note, Tiger comes with wxPython 2.5.3.1, and that's what we're still running. I've checked the "recent changes" to see if this might have been fixed but doesn't appear to be.
Bob, I've run your code on Tiger with wxPython - both 2.6.1.0 and 2.6.1.1-pre20050615 and see the same problem. But if you explicitly do a dc.SetBackground() before clearing the DC it seems to do the trick:
def OnPaint(self, event):
dc = wx.PaintDC(self)
self.drawText(dc)
event.Skip()
def OnMouseMove(self, event):
if event.Dragging():
self.count = self.count + 1
dc = wx.ClientDC(self)
self.drawText(dc)
def drawText(self, dc):
dc.SetBackground(wx.Brush("white"))
dc.Clear()
dc.SetFont(self.font)
txt = "count: " + str(self.count)
dc.DrawText(txt, 20, 20)
David, -- Thanks much! That indeed does the job. After playing around with it, this seems a bit more general for all platforms.
dc.SetBackground(wx.Brush(self.GetBackgroundColour()))
Although it has no effect on the immediate problem, the PaintDC in your original code is never used - drawText always creates a ClientDC.
Yes, you're right. In cobbling up this little sample I overlooked this point.
Thanks again,
Bob
I'm not sure what you're ultimate goal is, and this looks like a little test case that isn't what you really need. However, you probably don't want to call dc.clear inside a Mouse Move event, you're going to get a LOT of flashing!
My inclination would be to figure out a way to draw a rectangle over the old text, then draw the new text, or better yet, to re-draw the old text in the background color, then draw the new text. you'd get a minimum of flashing that way.
Option 3: buffer it. Draw the text to an off screen buffer, with a wx.MemoryDC, then blit that buffer to the screen. That way you get a one-time switch from the old text to the new, without a blank in between.
On OS-X it may not make a difference, as I think it's double buffered anyway, but it will work better on GTK and Windows.
As usual, this got me thinking, so I've enclosed an example. I made the font bigger, as the flashing was more pronounced with a large font. My version has no flashing at all.
I've also fixed the OnPaint handler, to use the PaintDC.
-Chris
MoveText.py (1.94 KB)
···
--
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:
Option 3: buffer it. Draw the text to an off screen buffer, with a wx.MemoryDC, then blit that buffer to the screen. That way you get a one-time switch from the old text to the new, without a blank in between.
As usual, this got me thinking, so I've enclosed an example. I made the font bigger, as the flashing was more pronounced with a large font. My version has no flashing at all.
Chris, -- thanks for looking into it. Couple of days ago David Hughes suggested a solution which solved my problem (of text being overwritten) but as I take a closer look, there is some flicker (since in the real program there is much more text displayed) and I agree, double buffering is the way to go.
However there is a problem with your program which I haven't been able to fix. On my Win2000, python 2.3.4, wxPython 2.6.1.0, all I see is white background, I don't see any numbers as I drag the mouse. I tested this on a OS X Tiger and there it work OK. I assume you tested this on Linux.
Can somebody test this work on XP? This could be a bug in wx. I've re-attached the program again.
Bob
MoveText.py (1.94 KB)
Bob Klimek wrote:
However there is a problem with your program which I haven't been able to fix. On my Win2000, python 2.3.4, wxPython 2.6.1.0, all I see is white background, I don't see any numbers as I drag the mouse.
Do you see any text? I did a very kludgey thing and just guessed at a buffer big enough to hold the text. If the font ends up much bigger on Windows, the buffer may not be big enough. As you specify font sizes in "points", and everything else in pixels, this can be a problem when you move things between systems.
If there is no text shown, this could be an issue I discovered a while back that on Windows, you can't draw a bitmap that is currently selected into a wx.Memory DC.
Note that what you probably want to do is buffer the whole Window, not just the text.
I've enclosed a new version, fixing both of those issues:
-Chris
MoveText.py (2.39 KB)
···
--
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:
Do you see any text? I did a very kludgey thing and just guessed at a buffer big enough to hold the text. If the font ends up much bigger on Windows, the buffer may not be big enough. As you specify font sizes in "points", and everything else in pixels, this can be a problem when you move things between systems.
If there is no text shown, this could be an issue I discovered a while back that on Windows, you can't draw a bitmap that is currently selected into a wx.Memory DC.
Note that what you probably want to do is buffer the whole Window, not just the text.
I've enclosed a new version, fixing both of those issues:
This version works! The thing that made the difference is the " del mdc" line. Adding that line to your original program makes it work as well.
I find this odd because dc normally never has to be explicitly deleted. In fact I don't recall ever seen it done. Is this some workaround to get around a wxPython bug?
In any case, thanks again!
Bob
Bob Klimek wrote:
This version works! The thing that made the difference is the " del mdc" line. Adding that line to your original program makes it work as well.
I find this odd because dc normally never has to be explicitly deleted. In fact I don't recall ever seen it done. Is this some workaround to get around a wxPython bug?
It's a wxWidgets issue, and I don't know whether it is a bug or a "feature", but it bit me in the past, and took a LONG time to debug that time, so I remembered it this time. I had even documented it in the Wiki:
http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies
You don't have to delete the DC, you could also just select the bitmap out of it but without the bitmap it' snot very useful.
If you use the DC.Blit method, then you can leave the MemoryDC alone. Indeed you need to, as you're blitting from one dc to the other.
-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:
Bob Klimek wrote:
This version works! The thing that made the difference is the " del mdc" line. Adding that line to your original program makes it work as well.
I find this odd because dc normally never has to be explicitly deleted. In fact I don't recall ever seen it done. Is this some workaround to get around a wxPython bug?
It's a wxWidgets issue, and I don't know whether it is a bug or a "feature", but it bit me in the past, and took a LONG time to debug that time, so I remembered it this time.
Perhaps we should revisit this with Robin when he gets back. If it's a "feature", it doesn't feel natural.
Bob
Bob Klimek wrote:
It's a wxWidgets issue, and I don't know whether it is a bug or a "feature", but it bit me in the past, and took a LONG time to debug that time, so I remembered it this time.
Perhaps we should revisit this with Robin when he gets back. If it's a "feature", it doesn't feel natural.
If you'd like to see this addressed, I'd post a question to wx-users and/or wx-dev. I imagine someone there will now if this is hard limitation of win32, or something that could be fixed.
-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:
Bob Klimek wrote:
It's a wxWidgets issue, and I don't know whether it is a bug or a "feature", but it bit me in the past, and took a LONG time to debug that time, so I remembered it this time.
Perhaps we should revisit this with Robin when he gets back. If it's a "feature", it doesn't feel natural.
If you'd like to see this addressed, I'd post a question to wx-users and/or wx-dev. I imagine someone there will now if this is hard limitation of win32, or something that could be fixed.
Chris, I just did. I had some problem subscribing to the wx-users mailing list, but it seems ok now.
Bob
Bob Klimek wrote:
If you'd like to see this addressed, I'd post a question to wx-users and/or wx-dev. I imagine someone there will now if this is hard limitation of win32, or something that could be fixed.
Chris, I just did. I had some problem subscribing to the wx-users mailing list, but it seems ok now.
You already got an answer. Apparently it is a "feature" of Win32, and thus there isn't anything wxWidgets can do about it.
Oh well.
-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:
Bob Klimek wrote:
Chris, I just did. I had some problem subscribing to the wx-users mailing list, but it seems ok now.
You already got an answer. Apparently it is a "feature" of Win32, and thus there isn't anything wxWidgets can do about it.
To close this out, here's the reply I got from wx-users list.
···
***************************
It's not a bug, per se, it's a quirk of Windows. Selecting a bitmap
into a wxMemoryDC "locks" the bitmap, and it can't be accessed by
another DC. Deleting the wxMemoryDC will de-select the bitmap (you
could also manually de-select - deletion per se is not required). I
believe this is documented under wxMemoryDC, if not, it perhaps should
be. I can't think of anything wx can do to try to "fix" this
situation.
***************************
Bob