[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Dirty rect overlapping optimizations





On Mon, Mar 27, 2017 at 8:08 PM, Ian Mallett <ian@xxxxxxxxxxxxxx> wrote:
Hi,

Just a couple quick, miscellaneous notes on this problem:

--IDK if pygame does this, but I expect blitting, with overdraw, to a fullscreen temporary surface, and then sending the whole surface every frame to the GPU would be faster than updating multiple smaller portions of the GPU memory with CPU data.


Double buffering works like that. Except with update you can tell it to update only parts of the back buffer. When you display.flip()/update() it sends the data. It's faster because less data is sent over the bus. But even on OpenGL slower implementations (or with higher resolutions) you can gain benefits by only updating part of the buffer(s). Not on monster dedicated cards at lower resolutions of course.
 
--Dirty rects were never really a performance issue for me. This is partly because I usually implement the scheme above, more-or-less, partly because I avoid it algorithmically, and partly because blitting is inexpensive and typical overdraw rates are low (as they would be in a good GPU renderer too).

--IIRC the fastest algorithm for rect-rect collision detection is the max-of-mins/min-of-maxes method, which is widely known. It maps nicely to SSE too.


Sounds interesting. Maybe that's what we're using now for rect collision... I'm not sure of the algo name. It's only in C however.



Below is one of the cases that benefits the most. (actually after drawing this I'm not sure if this is actually true or I dreamed it up... but I drew the diagrams... so it feels a waste to delete them).

Currently the update method combines two rects like this:
_______
|     |
|   __|____
|___|_|
       |
    |     |
    |     |
    |_____|


Into a big rect like this:
___________
|     ####|
|     ####|
|   XX    | # - updated, but no need.
|###      | X - over drawn.
|###      |
|###______|


Note in these crude diagrams the # area is drawn even though it doesn't need to be, and the XX is over draw. When there are some overlapping rects like this that are large, that can be quite a saving of pixels not needed to be drawn.