You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our renderer is really inefficient. Most non-trivial programs (see followmouse and reversi examples) end up experiencing a lot of lag. Re-rendering everything from scratch every frame was a good enough strategy when this project was starting, but we're going to need a much better alternative in order to keep pushing this project forward.
A couple of considerations:
Unless we are currently filling, redrawing everything is usually pretty wasteful
We can't stop redrawing everything every frame as it is now because we draw the turtle and the turtle is constantly moving
If we could efficiently blit an image onto the screen every frame (piston graphics doesn't provide many easy ways to do this), we could potentially draw everything onto a separate buffer and then render that on to the screen quickly (a double-buffered rendering technique)
Idea: Double-Buffered Rendering
The double-buffered rendering technique would look something like this:
We draw every Drawing in a separate buffer called the drawing buffer.
If begin_fill() is called, we stop drawing into the drawing buffer until end_fill() is called
When end_fill() is called, the entire filled shape is drawn into the drawing buffer at once.
In every frame, we first copy (blit) the drawing buffer onto the screen. We then draw the current filled shape (if any) and the temporary path (if any). Then, at the very end we draw the turtle.
If we can buffer the turtle drawing and then quickly blit a rotated image of it onto the screen, that would be even better
By buffering everything like this, we only have to copy an image onto the screen (which is very fast) and then perform up to 3-4 other drawings. This (in theory) is much faster than redrawing every single shape every time. There are certain cases like when clear() is called or when the background color changes that we would still need to redraw everything. However in the common case, this strategy is very efficient.
We would need a framework with appropriate APIs for implementing this.
Help Wanted
I am not an expert in graphics so this may not even be the best way. This idea is based on my experience with the HTML5 Canvas API, so low level graphics may prefer something completely different. I am very open to help with this and would love for someone to write a more efficient graphics backend for turtle.
The text was updated successfully, but these errors were encountered:
Our renderer is really inefficient. Most non-trivial programs (see
followmouse
andreversi
examples) end up experiencing a lot of lag. Re-rendering everything from scratch every frame was a good enough strategy when this project was starting, but we're going to need a much better alternative in order to keep pushing this project forward.A couple of considerations:
Idea: Double-Buffered Rendering
The double-buffered rendering technique would look something like this:
begin_fill()
is called, we stop drawing into the drawing buffer untilend_fill()
is calledend_fill()
is called, the entire filled shape is drawn into the drawing buffer at once.By buffering everything like this, we only have to copy an image onto the screen (which is very fast) and then perform up to 3-4 other drawings. This (in theory) is much faster than redrawing every single shape every time. There are certain cases like when
clear()
is called or when the background color changes that we would still need to redraw everything. However in the common case, this strategy is very efficient.We would need a framework with appropriate APIs for implementing this.
Help Wanted
I am not an expert in graphics so this may not even be the best way. This idea is based on my experience with the HTML5 Canvas API, so low level graphics may prefer something completely different. I am very open to help with this and would love for someone to write a more efficient graphics backend for turtle.
The text was updated successfully, but these errors were encountered: