PicoVector Enhancements & PicoGraphics Layers #1019
Conversation
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
2 times, most recently
from
7053bfa to
5d92aeb
Compare
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
2 times, most recently
from
5b2e806 to
f2d84fa
Compare
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
from
e6d4182 to
96beb08
Compare
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
5 times, most recently
from
633d387 to
f4409d8
Compare
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
from
f4409d8 to
01d8aa7
Compare
Add preliminary support for multiple layered drawing surfaces. Allows, for example, static content to be loaded into one layer and remain unmodified while the above layer contains animations. Particularly useful for drawing PNG or JPEG UI elements which are then overdrawn with text or animated elements, without paying the cost of loading/decoding every frame.
Ignore sign compare and narrowing conversion errors in pretty-poly.h.
Pointers were being incremented as if they were bytes, rather than larger containers.
pretty-poly.h is not giving us fully clipped rectangles, so revert to the slower bounds checked pixel for now.
Since we're not using tracked allocation, any memory we don't explicitly hold a reference to will be assumed unused by MicroPython's GC. Pass up the pp_nodes and pp_node_counts points (hackily) to fix this.
Inline and simplify the pixel flip for a 13.2ms -> 3.8ms speedup at 128x128 on RP2350 stock. Drop RGB565 mode. Add the ability to stack some panels, eg: 2x128x64 in a 128x127 configuration.
~3.09ms to ~2.87ms per frame without overclock.
Gadgetoid
force-pushed
the
feature/picovector2-and-layers
branch
from
01d8aa7 to
762c5cb
Compare
Fix spurious point in top-left corner causing a broken triangular rectangle when any permutation of corners other than the bottom-left is rounded.
For some reason this was unset causing drawing to fail. Reset it to a known good state in the constructor.
PicoVector: Fully initialise text metrics.
Hub75: Fix LED ghosting.
|
What's the status of this PR? I guess I'd want the Vector changes so I can play with the Tufty 2040 more, and I'd also love to try layers there - or maybe at least some kind of Double Buffering for moving text on top of a a PNG ... |
|
You can grab one of the test builds from here: https://github.com/pimoroni/pimoroni-pico/actions/runs/12372911360?pr=1019 There's also something resembling documentation here: https://github.com/pimoroni/presto/blob/main/docs/picovector.md |
ooooh there goes my sleep tonight 😆 thanks! |
Can relate! PicoVector is still getting the rough edges bashed off, but it's close to release. Or, at least, I haven't run into a serious bug for a while. Any feedback would be welcome! |
|
heh, let's see. probably something for 38c3 next week ... what I'd actually want is an SVG loader (for something minimal, though) - I actually need tufty as a badge, and want it to |
Merges and replaces #853 and #1011, since these features both relate to drawing and we usually need both of them in experimental builds.
experimental/psrambranch of MicroPython which we ideally don't want in production. If/when we merge these features, this CI change should not be included!PicoVector
Incorporates the updated Pretty Poly library, which required a near complete rewrite of Pico Vector and will probably inform a redesign of the Python API.
There's now a proper C++ PicoVector library which will underpin the MicroPython bindings.
Alright Fonts are in an absolute state of turmoil, pending us figuring out how they might work. As the very least, the "af" format might change and break compatibility with the initial PicoVector release.
This is all a bit of a pain, but it will hopefully be worth it.
Hub75 / Interstate75
Dropped RGB565 mode altogether, it should never be necessary since the displays are very low resolution anyway. Currently the largest supported display needs 64kb. If/when we add other modes, we should support them all and caveat that they will be much, much slower to flip.
Increased performance of RGB88 mode flip from 13.8ms down to about 2.87ms. This should make it much more feasible to hit 60FPS since user code costs additional time over these baseline numbers.
Layers
Add preliminary support for multiple layered drawing surfaces.
Allows, for example, static content to be loaded into one layer and remain unmodified while the above layer contains animations.
Particularly useful for drawing PNG or JPEG UI elements which are then overdrawn with text or animated elements, without paying the cost of loading/decoding every frame.
Support for two layers is currently hard-coded for RGB332 and RGB565 pen types. There is no alpha blending, a pixel from the top layer is shown if it is not black (0) otherwise the underlying layer is displayed.
Since RAM usage is a multiple of layers, RGB332 will take 320240num_layers and RGB565 would be 3202402*num_layers, this is very much better suited for Pico 2 albeit RGB332 works well on a Pico.
Layer support is provided by the
frame_convertfunction, as such it must always be called, even if the display native type matches the graphics buffer. EG: ST7735 and ST7789 displays supporting RGB565 now must callframe_converteven if your display buffer is RGB565. This could be improved by checking the number of layers and skipping the call if it's 1.TODO
layers=should belayered=set_layer) is called?