Open nbrr opened 4 years ago
The current canvas performance strategy is to:
use the framebuffers pixel storage format (a vector of u8) and once a run loop is done, literally just write it out to framebuffer (using the lib)
taking advantage of copy_from_slice
as it's extremely fast compared to iteratively copying numbers (it uses memcopy
under the covers I think)
helloworld
is fast because it never clears the screen, it just writes a pixel at the current touch location
draw_image
is fast because it uses copy_from_slice
to copy rows of image' pixels at a time
clear_color
is fast, because it creates an array of pixels that's the whole size of the visible canvas, and literally just copies over the whole canvas pixels
I think layers is a cool idea, but I have concerns about this PR's direction because it seems to be moving toward a direction that will inevitably require for looping over large Vec of pixels to get something into a frame buffer (as opposed to taking advantage of copy_by_slice
somehow).
I think in general i'm not sure why layers have to be a part of a canvas itself. In my mind, I just see canvas as a low level structure that we can efficiently modify.
I see canvas more like how you seem to be describing Layer
(which was probably why I was wanting to call it Surface), but with a pixel format that matches the underlying framebuffer.
Here is a PR so that we can study difficulties related to #9.
Canvas
holds a vec ofLayer
. Layers are meant to represent a depth in the scene to draw. Each layer has an array ofOption<Pixel>
representing whether a layer has something to display on a particular pixel. They are meant to be ordered so that only the top-most layer is will actually be displayed.I think eventually it'd be best that each layer has a reference to the canvas that holds it so that we can manipulate the layers on their own. In the approach I took it is necessary to go through the canvas because I attempt to keep the canvas' pixels up to date regarding which is the top-most pixel as I update some layer's pixel. I went this way because for-looping the whole thing to determine the top-most pixels each time I want to display was way too slow. However in the drag example I want to clear a layer from the line drawn at the previous iteration. I used a for-loop and this step makes it very slow. I'm not sure what to do. Maybe use a map of coordinated -> pixels so that active pixels of a layer are easily accessible without need to go through the whole thing? It doesn't seem convenient though. I am also worried that we might eventually run into this problem anyway at some point since writing something on the whole screen does seem like something trivial one would want to do. How is the
helloworld
example actually performing since that's what it does?