I am now testing this with a wearable LED board running off of a 3.7V battery (https://twitter.com/GeekMomProjects/status/1498158499527680002) and I LOVE it!!! I’ve just started looking at both changing the clock rate and also WiFi off mode, so I don’t have quantitative results yet, but qualitatively, just running animations at 160 MHz vs 240 MHz has made the board run MUCH cooler without noticeable reduction in animation quality. Fairly high heat output from the PixelBlaze Pico was a significant problem for me with the Pico & wearables, and I think this will solve it. Turning off WiFi takes the current down another 90 mA or so (judging by eye - will do more quantitative testing later) and takes the temperature of the board down from “warm but wearable” (at 160 Hz) to unnoticeable.
Also - just tried the 80MHz mode with WiFi, and (qualitatively) the framerate has dropped to about 70 FPS from close to double that, and while I can see a difference, I doubt that anyone else would . This board has only 61 pixels, so I don’t know whether it would be more obvious in a larger, more complex LED array, but it works great for my purposes, and, more importantly, doesn’t run too hot to wear.
Thank you for implementing this. Will be getting myself some more Pico boards ASAP!
Mostly, “yeah, no problems”. Frame rates are unchanged, for all practical purposes, I really love the new power management features.
The preview in the editor though, is not working for any of the matrix and cube configurations I’ve tried. The colors seem to be correct, but the pixels are displayed out of order. Output to LEDs is fine. Did I maybe miss something in the configuration?
There can be a bit of weirdness if the pixel map size doesn’t match the pixel count. If you regenerate the pixel map (add a whitespace or something) does it fix?
You might also see gaps if the pixel count is over 1000. There’s a setting in the global for fill gaps that can help, but it picks a neighbor pixel based on index, might not look good for all maps.
If that doesn’t fix it, can you post a screenshot / video?
Thanks, @wizard!
I played with this a bit more last night and it looks like it’s due to an upgrade that didn’t quite succeed, possibly due to low memory. (This PB3 was at 317k available when I upgraded.)
I restored it to its pre-upgrade state with esptool, erased a bunch of patterns and did the upgrade again. Now everything works fine.
My only remaining issue is that LED output frame rates are running at 80-90% of what they were in v3.20. Turning the previews off doesn’t make a significant difference. Probably just debug code, so no real worries. The new UI is really beautiful. And useful too!
Works well for me so far, the speed options are cool for wearables
And yes I’ve noticed a small drop in reported speed too, serpinski rainbow down from 147 fps to 112. My eyes couldn’t tell the difference though even after bumping the speed to medium and I was getting 98fps
New version, this is a release candidate, and will go live in a day or so unless folks see bad things! Not too much changed over last version, but a few nice quality of live improvements.
The pixel mapper has a setting to maintain aspect ratio:
Fill - If necessary, the map will be stretched or squished to fit every dimension.
Contain - The map keeps its aspect ratio, but is resized to fit the largest dimension.
Changes to config write two copies and only overwrite the second file if the first is successful. This should prevent any kind of wifi/power issues from losing your working config. A revision counter keeps track of modifications so that it loads the newest valid config if they don’t match.
Added a small cross in the center of the preview so you can tell where the center is.
Mapped pixels beyond the configured number of pixels show as gray.
Backup + restore moved to main settings tab, reboots after a restore to load config.
Added docs for new controls
Given the limited space in V3 and the huge preview size increase for 1K pixel previews, it now downscales the saved previews to 100 pixels wide (same as previous versions), and try to compress them to 5KB.
Fixed sliders on safari (was black on black)
Hidden stuff for the curious:
previewSettings.globalCompositeOperation can be changed. Handy if you have many very tightly packed pixels.
Working well here! Upgrades went smoothly and performance is very good. What I’m seeing is that it is roughly the same as v3.20 on patterns that use frame buffers, and appreciably faster on patterns that don’t. (Matrix Green Waterfall is up from 78fps to 90!)
The FPS differences are interesting… Nothing on the rendering side changed. I wonder if things are subtly shifting flash locations and causing more instruction cache hits/misses depending on where they get linked.
Interesting. That sounds possible. Is this reproducible for you?
I tested again on couple of Pixelblazes hooked to 256 pixel WS2812 displays, with different pattern lists. The performance change is consistent.
The patterns that show the most difference for me are things like Matrix Green Waterfall and Spinwheel 2D. Both of these patterns have relatively uncomplicated code in render2D(), and spend most of their rendering time just calling math functions in the vm.
Can you ID those (any other patterns I mean) for me? I have a set of performance unit tests that I run, but it does a small single thing at a time. Might be some combination of diverse code that snags. I can add snippets of the patterns to the unit tests, get a baseline, and monitor for the future.
I’ll look at “Matrix Green Waterfall” and “Spinwheel”
@wizard, jsut to be sure we’re on the same page those two patterns are actually about 10fps faster on the new firmware than on v3.20!
One other small thing: Preview quality is slightly better on Chrome than on Firefox. I wouldn’t advocate messing with it right now - just something to play with in the future when you have time.
Here’s a terrible picture, many reflections. Left to right are (1) Firefox 90.0.1, (2) Pixel Teleporter, (3) Chrome 99.0.4844.74. You can see Firefox looking a bit odd. (And Pixel Teleporter is here to show how good these previews actually are – I wrote PT to help with development, and and for most purposes, I’ll now be using the web previews for development instead!)
The dotScale2D is the size of the circle it will draw, this is scaled down based on the number of pixels and the aspect ratio.
The dotMidStep2D setting defines the midpoint for the gradient, the first element is the position/radius, the second is the alpha, going from solid to the midpoint setting to transparent.
You’re right - a little playing with previewSettings fixes it. I suspect it’s caused by weird stuff unique to my setup. I’m running on a high DPI monitor with a custom (large-ish) UI scale factor. (This is how I dodge needing reading glasses to program!)
Firefox probably ignored a piece of scaling information somewhere. Or there’s a browser setting I don’t know about. Here in the Land of Flawless Browser Compatibility, it’s not that surprising.
I’m pretty sure I actually can get PT’s geometry and shaders running in WebGL. I was planning to, because I want to do a P5.js port. When I do, if you like how it looks and runs, you’re welcome to it! In any case your 3D previews look miles better than the current Pixel Teleporter build. IMO, this firmware update is a real triumph on a lot of fronts!
