Bad performance when animating

[elpiel]

• Version of embedded-graphics-simulator in use (if applicable): 0.3
• Version of embedded-graphics in use (if applicable): 0.7

Description of the problem/feature request/other

It seems that the simulator has a very bad performance when it comes to doing animation with SDL2.
When I was testing I got ~15 FPS with BinaryColor & 8-9 FPS when using Rgb888 (or Rgb858, I forgot which one).

One way I saw performance gets crippled even more is by using scale > 1.

Another performance bottleneck could be the creation of texture on each Sdl2Window::update call:

simulator/src/window.rs

Lines 249 to 263 in 96e8a36

	pub fn update(&mut self, framebuffer: &OutputImage<Rgb888>) {
	let Size { width, height } = framebuffer.size();
	let texture_creator = self.canvas.texture_creator();
	let mut texture = texture_creator
	.create_texture_streaming(sdl2::pixels::PixelFormatEnum::RGB24, width, height)
	.unwrap();
	texture
	.update(None, framebuffer.data.as_ref(), width as usize * 3)
	.unwrap();
	self.canvas.copy(&texture, None, None).unwrap();
	self.canvas.present();
	}

• Is there a valid case where the size of the framebuffer might change?
• Are there any other places which might cause bottlenecks or is it the constant update of the full-display image that's the bottleneck?

Here's an example that can be run to see the performance in FPS with a simple text (for the FPS) and a very small 360p display & BinaryColor:

https://github.com/LechevSpace/embedded-fps/blob/main/examples/embedded_graphics.rs

[rfuest]

The simulator performance isn't great, but it shouldn't be that bad. Did you run your tests in release mode?

• Is there a valid case where the size of the framebuffer might change?
• Are there any other places which might cause bottlenecks or is it the constant update of the full-display image that's the bottleneck?

I never measured the performance impact of this code, but I was aware that recreating the texture every frame isn't perfect when I wrote it. There was some kind of lifetime issue that prevented me from storing the texture for the entire lifetime of the window, if I remember correctly. I think that the sdl2 crate has a feature to opt into using unsafe code to work around this problem. But I never investigated this any further, because the change I implemented at that time was already a big improvement in performance and enough for my use cases.

I did write a prototype of a wgpu based GPU accelerated simulator some time ago, but that hasn't been released publicly. Using shaders to implement the scaling would have a much lower performance impact.

[jamwaffles]

The simulator is quite performant when run with --release but it's pretty much a necessity as performance tanks if the flag is omitted.

IIRC the simulator draws a small square for each pixel on the display, for scaling/spacing purposes which is inefficient but as @rfuest alluded to, good enough for most cases. Doing it in shaders is the ideal approach, but I'm not sure if SDL can do that in a cross platform way.

[elpiel]

Ok, thanks for all the feedback. Indeed it does improve a lot when running with --release flag, I got up to 230 FPS when running in release. It's still not ideal running in release all the time but I might look into it eventually.

It's good to know that there is such a performance impact which can be improved in the future 😋