Animation slowdown on OS X 10.11

[Ryan Holmes]

python 2.7.11

wxPython 3.0.2.0

I have a custom widget that is basically a gauge to measure a resource or whatnot. My application has been using this widget for years without any problem.

We recently made the switch to wxPython 3.0, which brought it's own problems, most of them solved already. We also started getting reports that our custom gauge animations are lagging very badly when there is more than a couple updating, the lagging getting worse as the number of currently updating gauges increases. This slowdown only happens on OS X 10.11. It is fine on 10.10 - 10.7 (our lowest supported OS X version). Seems to work in 10.11 fine when run with wxPython 2.8.

Here are some gifs of the described problem. Unfortunately the OS X gifs are potato quality, but it's the best that I could do as I tried many screen capture programs that didn't work and had to settle for some crap quality one.

(each test has 16 gauges)
Windows: https://gyazo.com/5dd3982ee2ec9c4f92f27a196fab5b41 Shows how it's supposed to look and how snappy it is
OS X 10.10: http://www.gfycat.com/GreedyHelplessAltiplanochinchillamouse 10.10 works well
OS X 10.11: http://www.gfycat.com/PassionateDefiniteGoat 10.11 is majorly laggy when updating multiple gauges at a time 

Here is the test application code:

https://gist.github.com/blitzmann/cd698a62b741dd9a163a

Can anyone give any insight? I am not really a Mac person; I only have Hackintosh's to support development and investigate problems such as this.

[Chris Barker]

hmm, 

Mysterious.

Are you using Cocoa builds for both OS-X versions? 

Also, how are you updating the gauges? IF you are using  a wx.ClientDC, that may explain it -- OS-X like so control the rendering loop, when you use a clientDC, you are essentially saying: stop everything you're doing, draw my thing, then go back and pick  up where you left off. This can cause jittering and delays.

the "proper" way to do it is to do your rendering in a PaintDC, and call Refresh() and or Update() when something has changed.

All that being said, I found I couldn't get fast updating while moving the mouse without a ClientDC last time I tried.

- CHB

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Ryan Holmes]

Hi,

I should note that I only maintain this widget - I did not design or write it, it was part of the program long before I joined.

I am using wx.BufferedPaintDC to paint the gauges, and the gauge bar is drawn with wx.MemoryDC. It uses wx.Timer and an animation calculation to determine the next step of the animation and then paints it onto the screen with a wx.Refresh(). When there is only 1 gauge updated, everything is smooth. But when multiple gauges are updating at the same time, it slows to a crawl. =/

[Chris Barker]

On Fri, Feb 12, 2016 at 3:29 PM, Ryan Holmes <ryan.x...@gmail.com> wrote:

I am using wx.BufferedPaintDC to paint the gauges, and the gauge bar is drawn with wx.MemoryDC. It uses wx.Timer and an animation calculation to determine the next step of the animation and then paints it onto the screen with a wx.Refresh().

darn, then ClientDC isn't the problem. But much going on with the drawing? or is it just a blit to the BufferedPaintDC? In which case, I might try taking the BufferedPaintDC out of the loop, and using a regular PaintDC -- OS-X is buffered anyway, so I don't think it buys you anything , and maybe costing you something here.

-CHB

[Ryan Holmes]

Nope, lag is still present with wx.PaintDC. =(

I don't know why it is broken with only 10.11. We also have another 10.11-only GUI glitch with ListCtrl's not updating visually 0_o

[Ryan Holmes]

Also, I should note that it seems the actual timer runs at a good rate. Disabling wx.Refresh() in OnTimer() and calling it only when the timer gets the call to Stop (so as to update the gui) has the whole thing run in about 1 second, which is about how long it takes for other platforms. This leads me to believe it isn't something with the python implementation, and more to do with how OS X 10.11 renders the drawing. I just don't know if there is a work around for this (other than disabling animation, which I've already introduced the option for the users who experience it)

One of the folks that has relied to our issue about it had this to say:

> Keeping Refresh() call but returning immediately from the top OnPaint() while a timer is running is also super slow. May indicate that it's the refresh/idle queue in wx that's causing issues, rather than pyfa's drawing implementation.

Dunno how I would test for this or fix it.

[Chris Barker]

well, I'm well out of my depth, sorry :-)

I'm not sure how to profile this at the C++ level but that may be what's needed.

(though a regular python profile might be a good start).

I'd bump this to the C++ wxWidgets list or issue tracker.

-Chris

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Holmes]

I will try to find the wxWidgets list and post there then. We also have an issue where a mouse rollover has a delay (again, this is a custom widget. Haven't really looked into it at all, but I'm sure it's the same Refresh() delay as discussed):

https://www.youtube.com/watch?v=mYoFabipVGE&feature=youtu.be

Again, only on 10.11. So odd. Hopefully someone will chime in that can point to answers. =)

[Chris Barker - NOAA Federal]

Again, only on 10.11. So odd. Hopefully someone will chime in that can point to answers. =)

I'm not running 10.11, so I can't even test :-(

But maybe someone could confirm the issue isn't somehow peculiar to your system.

CHB

[Ryan Holmes]

Well, in that regard, I have quite a few users of my application that have experienced the issue. All of them running 10.11. I've posted on the wx-dev group about the issue. Not really looking to get it fixed per-se (if it is a wxWidget issue, then it's not feasible to wait for them to fix it, then wait for wxPython to catch up), just want an answer as to what is happening. 

We shall see!

- Ryan

--
You received this message because you are subscribed to a topic in the Google Groups "wxPython-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wxpython-users/ZQD2I-MrAqg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wxpython-user...@googlegroups.com.

[Ryan Holmes]

I'm posting to give a quick update in case this thread is stumbled upon.

I have made a discussion thread at wx-dev, but it hasn't progressed anywhere partly due to the complex example I gave at first and partly due to it being in Python 

Link to discussion: https://groups.google.com/forum/#!searchin/wx-dev/animation$20slowdown/wx-dev/vZs6wCNn0dY/I0aqfAOsGgAJ

However, I have made a much simpler example that I believe is related to the original issue, my latest post describes it. I am hoping its simple enough for someone to port a working and demonstrable example to C++ and use wxWidgets directly. We hall see. 

-- Ryan

On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote: