Lasso is just one example. I just noticed that using a timer to "page" through multiple frames of data (not an animation, so no blitting), is also causing flickering, although not nearly to the same amount as the lasso. I think I might have a few draw()'s in the code because draw_idle()'s weren't working. Maybe the Wx rework changed some of the old behaviors?
I think I just figured out how the rubberband/lasso tool is implemented. It's extremely fragile:
It is not drawn in the blit-path in paintEvent at all
It is never cleared by event handling, currently it is cleared directly after the first paintEvent
This causes the lasso to disappear if there is any additional paintEvent between paintEvents that originated from lasso mouse move events. Also, the lasso stays on screen if the first paintEvent call from Qt happens after the zoomed draw request when the mouse is released. I'll propose a fix to that in #4962.
I'm seeing no lasso flicker for the normal qt gui by the way, are you talking about the ion() mode? For this there is a pretty good explanation. Those draw_idle() callbacks we talked about are causing additional paintEvents the current lasso implementation cannot cope with. The PR from @jrevans with the old draw_idle() implementation hides this problem because it discards the callbacks.
Activity
tacaswell commented on Aug 20, 2015
This is probably related to the auto-redraw 😞
Are you using it with or with out blitting?
WeatherGod commented on Aug 20, 2015
Looks like useblit=True for this one.
tacaswell commented on Aug 20, 2015
That is better that what the qt4 backend is doing for me, no flicker, but also no line!
WeatherGod commented on Aug 20, 2015
really? I must have forgotten to try lassoing on that backend. I tested gtkagg and tkagg as well.
tacaswell commented on Aug 20, 2015
Things are way broken on master with the lasso example we ship, draw is getting spammed like mad.
WeatherGod commented on Aug 20, 2015
Lasso is just one example. I just noticed that using a timer to "page" through multiple frames of data (not an animation, so no blitting), is also causing flickering, although not nearly to the same amount as the lasso. I think I might have a few draw()'s in the code because draw_idle()'s weren't working. Maybe the Wx rework changed some of the old behaviors?
WeatherGod commented on Aug 20, 2015
Removal of a polygon takes a few seconds before it finally disappears.
tacaswell commented on Aug 20, 2015
At least on Qt the issue I am seeing is fixed by the two Qt patches from @jrevans (#4943 & #4944).
attn @pwuertz
tacaswell commented on Aug 20, 2015
as a side note, for testing I just threw a print statement in Axes.draw to see how often it was getting hit.
pwuertz commented on Aug 20, 2015
I think I just figured out how the rubberband/lasso tool is implemented. It's extremely fragile:
This causes the lasso to disappear if there is any additional paintEvent between paintEvents that originated from lasso mouse move events. Also, the lasso stays on screen if the first paintEvent call from Qt happens after the zoomed draw request when the mouse is released. I'll propose a fix to that in #4962.
pwuertz commented on Aug 20, 2015
I'm seeing no lasso flicker for the normal qt gui by the way, are you talking about the ion() mode? For this there is a pretty good explanation. Those draw_idle() callbacks we talked about are causing additional paintEvents the current lasso implementation cannot cope with. The PR from @jrevans with the old draw_idle() implementation hides this problem because it discards the callbacks.
tacaswell commented on Aug 30, 2015
@WeatherGod Can you still reproduce this? Do we need to call in Robin?
Merge pull request #5352 from mdboom/fix-wx-flicker