Use strip.show() in a loop

Hi,
I’ve developed a usermod that displays pixel art images on a 2D matrix, loaded from a server. Overall it’s working ok, and I’m close to releasing some code. More details here:

I’d like to crossfade between loaded images. At the moment, performance in the crossfade is dictated by how often handleOverlayDraw() is called. This, in turn, is dictated by whether WLED is set to show a solid colour or an effect. If an effect is enabled, then frame rates are better, but there’s also the performance overhead of redrawing the effect, which is completely hidden by my usermod anyway.

I saw this issue, but I don’t think overriding the defaults in a custom build is a great solution.

During the transition between images, I want to call strip.setPixelColorXY() and then strip.show() in a loop. At the moment, this causes Bad Things™ to happen, as it recursively calls handleOverlay() .

Reading the source of WS2812FX::show() , the only option I think that I can see is to cache a reference to the callback, set it to null, and then I can use show() without restriction, restoring the cached reference when I’m done.

Is there another way around it? Is calling busses.show() an acceptable workaround?

Touching anything other than strip.something or SEGMENT.something is bound to break in the future.

As of 0.14 you can write an effect function in the same way internal effects are written and include it in your usermod. I’ve posted instructions on how to do that elsewhere on the forum and/or discord.

Basically you write myEffect() function and then add strip.addEffect(myEffect,...) in your usermod’s setup(). In such case your usermod effect function is called each time display update is due.

Using handleOverlayDraw() will only update display at time intervals original effect on segment intended.

And you should never call strip.show() (or, God forbid, busses.show()) on your own unless you want to break things.

Thanks for the reply.

I’ve registered a dummy effect that does nothing and left in the default slider to allow you to speed up performance. Is there a means to automatically select the effect in question and set the speed when the mod is enabled?

End result is here:

the custom server is here:

IMO this approach is not “correct” as a user may still select some other effect and have your usermod enabled.

I did briefly check your client code but skipped server as IMO that is too complicated for average user and as such I find it unappealing. IMO best approach should be to add SD card support and allow loading of images (in whatever format needed) from internal flash or SD card.

I would suggest to skip on handleOverlayDraw() and focus on effect function instead. Still… If it works for you… :smiley:

> IMO best approach should be to add SD card support and allow loading of images (in whatever format needed) from internal flash or SD card.

Which is exactly how Pixel Art Converter now handles it. Though the image(es) are stored in “WLED-optimized” form on the WLED-device. (minimal file size and strip ordered animations) @hughc I don’t know your use case, so you might “need” a client server based solution like the one you have built, if not this PAC feature will be ready for some beta testing soon. Send me a PM on discord :smile:

Should be noted, file size of animation now hardly demands any more than flash for images due to the “heavy lifting” of converting to WLED optimized format is done in the web browser unless you have very large animations or a lot of them.

Even though the sd card usermod is there I also don’t think SD need to be mandatory
for anything related to pixel art ( could be optional ) as this will surly reduce the number of users beside I do not see how using SD card will make it easier to convert images to json which is really the point if this step is straight forward then replacing the existing images should be fine and hence storing few images for about 10 gifs is a think reasonable to start with . I like you are using the pi for this but to be honest with you that is a showstopper for a lot of wled users due to cost