A bug / not understood feature related to screen updates

I don't have too much experience with graphics, but I'm pretty sure this isn't too good for performace. I enabled Highlight screen updates, and it showed something that didn't seem like it works like it should. Is this actually a bug?
ezgif.com-video-to-gif

I think you're going to have to be a lot more specific.
Can you reproduce in a Minimal Code Example?

2 Likes

Maybe when the two areas overlap the area drawn is the minimum rectangle that contains them both. But yes it is a bit odd.

Interested to see the code for minimal repro

I’ve also seen this behavior, and assumed it was intentional because it’s the simplest way to avoid redrawing over the same area multiple times per frame when there are overlapping dirty rects. The other way I can think of would be to slice up the dirty rects into smaller, non-overlapping rects and draw each slice separately, which seems like a lot of overhead (would require at least 2 draw calls per sprite per frame, one for the non-overlapping area and one for the overlapping area).

Sorry for not responding. I cannot send a minimal piece of code, because to replicate this, I'll have to send almost the entire 400 lines of code with a lot of art assets, but I'll explain what is going on. I have a (pre-generated) rotating image. Because it is being rotated, (aka switching between 361 pre-generated images), the size of the image increases and decreases, causing the image, to overlap with a line I draw every frame between 2 points. If I stand at a specific point in a certain way, it'll make the 2 constantly updated spots (because one has the image change repeatedly, and the other gets drawn every frame because it's not a sprite) overlap, causing a bounding box to update around them, instead of only the 2 rectangles.

Yep, that's how it works. The update list is a set of non-overlapping rects so that we're not redrawing the same area, as Dale noted, so the simplest way to do that is to union the rects when they overlap. We could do a bunch of work to split them into a bunch of smaller rects, but with a lot of sprites that will get really messy. I'm sure the overhead of having to process a huge list of tiny rects would outweigh any savings it might provide.

Related: if you do have a lot of small sprites, it's often faster to skip the dirty rect processing and redraw the entire frame every update. See playdate.graphics.sprite.setAlwaysRedraw(flag)

1 Like