Probably on the resize event also nuke the blit quue?

Probably on the resize event also nuke the blit quue?

Strangely doesn't work.

Would it make sense to utilize collections.deque here? Considering that blitting is for performance reasons, it might make sense to use it.

Would it make sense to utilize collections.deque here?

No, only matters if you care about the ordering of the popping, which we don't here.

Strangely doesn't work.

Could it be due to the stale flag?

unlikely, that only gets considered to decide if there should be a full re-draw.

@dopplershift: The last commit here (5bde1ff) resolves the "glitches upon resize" issue (where the base parts of the figure outside of the blitted axes were not redrawn on resize). I have no idea if that's the right fix, but it should only decrease performance immediately after resizing -- it goes back to blitting only the minimal parts as normal right after that.

just had a thought. I don't know if it is applicable here or not. It is technically possible to have an animation that exists across figures (essentially, they would all share the same timer). Is this list of bboxes guaranteed to be only from the one figure being rendered?

The list of bboxes is sorted with the canvas which is 1-1 with figures. So even if they shared a timer (a single global resource), each figure would have its own list of bboxes.

attn @mfitzp @pwuertz @TD22057 as people who I think have worked extensively with qt + blitting.

I'm wondering if the blitboxes could be first combined into a bounding box in order to reduce the process to a single blit, but I guess there may be situations where this isn't necessarily a good idea. So without further profiling knowledge this looks good.

backported to v2.x as f6f1f13

Could probably justify backporting this to v1.5.x as well, but hopefully we will not do a 1.5.2 so the point is moot.