WinXP default controls & borderless window horrible

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

Paul Sijben wrote:

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

I've never seen this in my programs. Can you make a small runnable sample (http://wiki.wxpython.org/MakingSampleApps)? OS, wxpython version?

···

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org
Python Extension Building Network: http://www.pythonlibrary.org

Mike Driscoll wrote:

I’ve never seen this in my programs. Can you make a small runnable
sample ()? OS, wxpython
version?
Mike,

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

···

http://wiki.wxpython.org/MakingSampleApps

http://blog.pythonlibrary.org
http://www.pythonlibrary.org

wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

-- Paul Sijben tel: +31334566488
Eemvalley Technology fax: +31334557523
the Netherlands

http://eemvalley.com

Paul Sijben wrote:

Mike Driscoll wrote:

I've never seen this in my programs. Can you make a small runnable sample (http://wiki.wxpython.org/MakingSampleApps)? OS, wxpython version?

Mike,

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.

- Mike

Hi,

Paul Sijben wrote:

Mike Driscoll wrote:

I've never seen this in my programs. Can you make a small runnable sample
(http://wiki.wxpython.org/MakingSampleApps)? OS, wxpython version?

Mike,

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.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On Thu, Mar 5, 2009 at 6:45 PM, Mike Driscoll wrote:

Paul Sijben wrote:

Are you using MoveXY too? Do you know what the meaning is of the flags you one can pass to it?

See the docs for SetDimension (wxPython) or SetSize (C++).

···

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

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.

···

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

since I have a very complex app, cutting it down to some small piece of
code is a lot of work. Maybe this will help to show the problem.

I used my cellphone to make a short movie from the effect and put it at
livescore 088-Skor808: Cara Terbaik untuk Menikmati Hiburan Digital yang Seru-Score808 - Sport Live Streaming, Live Football and Basketball. Sorry the image is rather small.

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.

--
Paul Sijben tel: +31334566488
Eemvalley Technology BV fax: +31334557523
the Netherlands http://eemvalley.com
-----------------------------------------------------
EemValley Technology werft python & wxpython
programmeurs: http://www.eemvalley.nl/jobs

Paul Sijben wrote:

since I have a very complex app, cutting it down to some small piece of
code is a lot of work. Maybe this will help to show the problem.

I used my cellphone to make a short movie from the effect and put it at
livescore 088-Skor808: Cara Terbaik untuk Menikmati Hiburan Digital yang Seru-Score808 - Sport Live Streaming, Live Football and Basketball. Sorry the image is rather small.

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!

Robin Dunn wrote:

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

Paul Sijben wrote:

Robin Dunn wrote:

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!