SDL flip display very slow

Lines 323 to 324 in e3ad047

    
           // SDL loses texture contents, for example on resize. 
        
           al_backup_dirty_bitmaps(d);

This method calls al_backup_dirty_bitmaps every display flip, which is incredibly expensive. I found that the emscripten build of my game engines doubles in FPS with this line removed. ~90% of every frame was spent "backing up" two screen bitmaps every this was called.

I don't understand what problem it's fixing, and I guess resizing the browser window may not surface problems with Allegro resizing (The allegro display remains a constant size and the canvas is simply stretched way above Allegro-land). So I haven't fully tested the impact of simply removing this line.

How odd, I wonder if this is specific to some platform.

AFAIR this is simply impedance mismatch between Allegro API (which handles texture backup and restore transparently) and SDL API (which does not). Allegro does the same thing (calling al_backup_dirty_bitmaps) on Android and in DirectX backend, and there isn't really a way around it. This isn't "fixing a problem", this is simply implementing Allegro API guarantees, so it can't be removed.

What we could do is to let this be skipped via some display option or something in scenarios where losing the context is not expected to happen, as not every platform supported by SDL will exhibit such behavior. The whole auto-backup thing should probably be reconsidered for Allegro 6 if it ever happens.

Meanwhile, you can use ALLEGRO_NO_PRESERVE_TEXTURE for bitmaps you're drawing to in order to avoid the backup mechanism. I guess a similar option would be nice to have for screen bitmaps too for apps that always fully redraw their screen content at each frame. It would help with performance on Android too.

I can only speak for the emscripten usage: All my bitmaps are set to be preserved (no ALLEGRO_NO_PRESERVE_TEXTURE ), and with this line commented out I don't notice any bitmaps getting cleared like I would on other platforms w/ ALLEGRO_NO_PRESERVE_TEXTURE present. So if I understand things correctly, it seems this line is not necessary at least for web targets. Given that, could I send a PR to exclude this line when compiling with emscripten?

If there is a specific scenario I should test first to gain more confidence in this change let me know. Like ... would I only see an issue here if the browser decides to reclaim some memory from the GPU, and that would only happen if this flag is set? Is anyone familiar enough with the entire SDL -> OpenGL -> WebGL emscripten stack to say?

Emscripten is one of SDL-backed platforms where it does happen. WebGL does not guarantee a stable context.

	// SDL loses texture contents, for example on resize.
	al_backup_dirty_bitmaps(d);