Add support to draw to an off screen buffer #387
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #386
The basic design of the Graphics object is like following.
Graphics is declared as an empty abstract class. In case other renderers, have their own implementations of it. Almost each Processing API is also a method of
Graphics
object so I skipped defining abstract methods for each of them. As that would be too much redundant code and time-consuming.In the skia implementation, I am creating a new Renderer, canvas, surface, path and paint for each graphics object.
Then the methods are
binded
to the Graphics objects in a kind of unconventional way, but it works properly.The major scope of improvement here is to use a GPU-backed surface for smoother rendering. I need to dig more into how
glfw
contexts work and how can I create an offscreen context for surfaces.Currently it's a CPU backed surface and the offscreen sketches are not that smooth. I will open an issue for this.