Fix #6335: Queue boxes to update

[mdboom]

This fixes the issue where multiple animating axes would not all get updated. The reason this was broken is because blit sets a region to update, but there may be multiple blits between each opportunity to actually paint to the screen (on idle), so some will get thrown out. This changes things so there is a list (queue) of bounding boxes to update instead.

There is still the issue with glitchiness on resizing that I haven't been able to solve as easily.

Fixes #6335

[tacaswell]

Probably on the resize event also nuke the blit quue?

[mdboom]

Probably on the resize event also nuke the blit quue?

Strangely doesn't work.

[WeatherGod]

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

[mdboom]

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.

[WeatherGod]

Strangely doesn't work.

Could it be due to the stale flag?

[tacaswell]

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

[mdboom]

@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.

[WeatherGod]

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?

[mdboom]

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.

[tacaswell]

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

[pwuertz]

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.

[tacaswell]

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.