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.
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.
···
On Fri, Feb 12, 2016 at 11:31 AM, Ryan Holmes ryan.xgamer99@gmail.com wrote:
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.
–
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-users+unsubscribe@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.Barker@noaa.gov
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. =/
···
On Friday, February 12, 2016 at 3:30:40 PM UTC-5, Chris Barker wrote:
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.
On Fri, Feb 12, 2016 at 11:31 AM, Ryan Holmes ryan.x...@gmail.com wrote:
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.
–
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
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
···
On Fri, Feb 12, 2016 at 3:29 PM, Ryan Holmes <ryan.xgamer99@gmail.com> wrote:
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. =/
On Friday, February 12, 2016 at 3:30:40 PM UTC-5, Chris Barker wrote:
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
On Fri, Feb 12, 2016 at 11:31 AM, Ryan Holmes <ryan.x...@gmail.com> >> wrote:
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: Screen capture - 5dd3982ee2ec9c4f92f27a196fab5b41 - Gyazo 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:
pygauge.py · GitHub
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.
--
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
--
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-users+unsubscribe@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.Barker@noaa.gov
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
···
On Friday, February 12, 2016 at 7:08:22 PM UTC-5, Chris Barker wrote:
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
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. =/
On Friday, February 12, 2016 at 3:30:40 PM UTC-5, Chris Barker wrote:
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.
On Fri, Feb 12, 2016 at 11:31 AM, Ryan Holmes ryan.x...@gmail.com wrote:
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.
–
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
–
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
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.
···
On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote:
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.
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
···
On Fri, Feb 12, 2016 at 7:46 PM, Ryan Holmes ryan.xgamer99@gmail.com wrote:
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.
On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote:
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.
–
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-users+unsubscribe@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.Barker@noaa.gov
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):
Again, only on 10.11. So odd. Hopefully someone will chime in that can point to answers. =)
···
On Wednesday, February 17, 2016 at 2:19:59 PM UTC-5, Chris Barker wrote:
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
On Fri, Feb 12, 2016 at 7:46 PM, Ryan Holmes ryan.x...@gmail.com wrote:
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.
On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote:
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.
–
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
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
···
On Wednesday, February 17, 2016 at 2:19:59 PM UTC-5, Chris Barker wrote:
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
On Fri, Feb 12, 2016 at 7:46 PM, Ryan Holmes ryan.x...@gmail.com wrote:
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.
On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote:
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.
–
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
–
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-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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!
···
On Sun, Feb 21, 2016 at 8:30 PM, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
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
On Wednesday, February 17, 2016 at 2:19:59 PM UTC-5, Chris Barker wrote:
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
On Fri, Feb 12, 2016 at 7:46 PM, Ryan Holmes ryan.x...@gmail.com wrote:
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.
On Friday, February 12, 2016 at 2:31:16 PM UTC-5, Ryan Holmes wrote:
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.
–
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
–
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-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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: Redirecting to Google Groups
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:
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.