I notice that all the default controls I use in my application (textctrl
and statictext for instance) repaint themselves rather horribly when I
move my borderless window over it.
There seems to be an interaction between these two (my custom controls
do not suffer from this).
What do I need to tell windows when I have moved my Frame to refresh the
stuff underneath it in time before I get fading smears of the window I
am moving in the underlying window?
Paul
···
--
Paul Sijben tel: +31334566488
Eemvalley Technology fax: +31334557523
the Netherlands http://eemvalley.com
I notice that all the default controls I use in my application (textctrl
and statictext for instance) repaint themselves rather horribly when I
move my borderless window over it.
There seems to be an interaction between these two (my custom controls
do not suffer from this).
What do I need to tell windows when I have moved my Frame to refresh the
stuff underneath it in time before I get fading smears of the window I
am moving in the underlying window?
OS Windowx XP fully updated, wxpython 2.8.whatever is current
small runnable code might be a bit hard but if I am the only one seeing this there must be something with either:
* me moving the window using MoveXY, or
* using the DC to blit contents into my frame.
Are you using MoveXY too? Do you know what the meaning is of the flags you one can pass to it?
Paul
--
Paul Sijben tel: +31334566488
Eemvalley Technology fax: +31334557523
the Netherlands http://eemvalley.com
Well, I'm lost. I thought you were using regular widgets (like wx.TextCtrl), so why would you have to blit those? I don't know much about drawing my own controls or blitting. Hopefully Chris, Cody or Robin will jump in here and clear this up for you...
As for moving the Window, I've only messed with SetPosition. I'm not finding much for docs on MoveXY.
OS Windowx XP fully updated, wxpython 2.8.whatever is current
small runnable code might be a bit hard but if I am the only one seeing
this there must be something with either:
* me moving the window using MoveXY, or
* using the DC to blit contents into my frame.
wx.Window.Move (or MoveXY, it's the same) uses this call under the
hood in the C++ implementation:
SetSize(x, y, wxDefaultCoord, wxDefaultCoord, wxSIZE_USE_EXISTING)
The meaning of the parameter in MoveXY can be found in the wxPython
manuals, but if you leave it as default, the window size will not be
touched. So, in theory, the window will not be refreshed.
That said, I have found some problems myself in the Python
implementation of wxAUI when using Move(): the moved window leaves
behind a "trail" over the other widgets which takes a noticeable while
to refresh.
Now, without seeing some code it's difficult to guess: it may be a
weird interaction between Move() and dc.Blit(). If you could produce a
sample, we may be able to find an answer.
I am moving the window over a window from the wxpython demos and over
another of my own windows. There is a lag of the material I have blitted
into my window (the blue area with the gradient).
I checked and the DC operations believe they are filling within the window.
hope this helps
Robin Dunn wrote:
···
Mike Driscoll wrote:
As for moving the Window, I've only messed with SetPosition. I'm not
finding much for docs on MoveXY.
Under the hood Move and SetPosition are the same. SetPosition is a
simple wrapper around Move, which calls DoSetSize.
I am moving the window over a window from the wxpython demos and over
another of my own windows. There is a lag of the material I have blitted
into my window (the blue area with the gradient).
I checked and the DC operations believe they are filling within the window.
hope this helps
Paint events have a relatively low priority, so if there are other things going on then the paints can be delayed somewhat. That may be at least part of what you are seeing. One optimization you can make that may help out is to only paint the portion of the window that is in the update region.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Paint events have a relatively low priority, so if there are other
things going on then the paints can be delayed somewhat. That may be
at least part of what you are seeing. One optimization you can make
that may help out is to only paint the portion of the window that is
in the update region.
true. However that does not help other applications my window is
doodling on, as shown in the clip I linked.
The question is, are my DC blits doodling outside my window? Or am I
simply too CPU hungry (as Windows is notoriously bad at scheduling.) and
hence am I not giving the other windows time to update? Or is the
problem simply that my window has a blue background so it is so visible
that it leaves an after-image behind?
Paul
Paul
···
--
Paul Sijben tel: +31334566488
Eemvalley Technology fax: +31334557523
the Netherlands http://eemvalley.com
Paint events have a relatively low priority, so if there are other
things going on then the paints can be delayed somewhat. That may be
at least part of what you are seeing. One optimization you can make
that may help out is to only paint the portion of the window that is
in the update region.
true. However that does not help other applications my window is
doodling on, as shown in the clip I linked.
The question is, are my DC blits doodling outside my window? Or am I
simply too CPU hungry (as Windows is notoriously bad at scheduling.) and
hence am I not giving the other windows time to update? Or is the
problem simply that my window has a blue background so it is so visible
that it leaves an after-image behind?
It's hard to say without playing with it myself, but I would probably place at least some blame with Windows and/or the video driver.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!