Thanks to visit codestin.com
Credit goes to github.com

Skip to content

handleOverlayDraw setPixelColor Issues #5021

@mattpiper99

Description

@mattpiper99

What happened?

I have a usermod that implements handleOverlayDraw and back in the early version 15 days I could reliably call setPixelColor and it worked. Ever since around the time the segment "layering" stuff was introduced it has been broken - calling setPixelColor didnt result in the correct color being displayed. It could be unrelated to those changes, its just a rough timeframe when I updated my repository and it broke. I just today (10/23/25) updated my repo with the latest again and now it kinda works, but its still glitchy, as outlined in the issues below.

I am using a WS2805 strip and DigUno with custom compiled WLED on the latest version.

For troubleshooting, handleOverlayDraw() is super simple:

Segment& seg = strip.getSegment(0);
seg.setPixelColor(1, RGBW32(255,0,0,0));

...pixel 1 should be overridden to solid RED.

Issue 1 - Honoring Freeze/Unfreeze

Start with a single segment in state: on=true and freeze=false set to any color - it does NOT override the pixel. I have confirmed with debug output that handleOverlayDraw is getting called, but has no effect.

If I freeze the segment (freeze=true), the pixel DOES get set to red. Isnt this potentially backwards? When a segment is "frozen" normal effects do not display, and when it is "unfrozen" they do.

Issue 2 - FLASHING

Add a second segment:
-Segment 1: pixels 0-9 with on=true and freeze=false (should be "on")
-Segment 2: pixels 10-20 with on=false and freeze=true (should be "off")

Pixel 1 is flashing between RED (via handleOverlayDraw) and whatever default color the segment is set to. WLED reports that its displaying 333 frames per second, and it seems to be flashing about 3 times per second (captured on video and played back slowed down to count flashes), for whatever thats worth.

There seems to be something that happens by adding a second segment that changes the behavior reported in Issue #1 - where it actually does temporarily override the pixel, but then something else is happening to revert it back.

Issue 3 - Transitions Blocking handleOverlayDraw

Continuing with the setup from Issue #2 (segment 1 on/unfrozen and segment 2 off/frozen), if you set the "Fade" time to something like 3 seconds, and then turn ON segment #2, the flashing of pixel 1 red stops for the 3 seconds duration that the segment is transitioning on (or off). Once again I can tell via debug output that handleOverlayDraw is getting called during this transition but the setPixelColor call is having no effect - even though the transition is on a segment that does not overlap with the segment where the pixel is trying to be overwritten.

If you then unfreeze segment 2 (so both segments are on=true and freeze=false) the red pixel flashing stops and it is no longer overridden as it should be.

Observations:

I did notice that the frequency with which handleOverlayDraw is called spikes when adding a second segment (by adding a debug print line to the simple code above), and then if its deleted its called less frequently. Perhaps its expected that this function is called proportionally to the number of segments, but that seems contrary to my understanding that i thought it was called once before each time the strip is updated, which should be regardless of the number of segments? If that second segment is frozen then the rate drops back down.

To Reproduce Bug

(see above)

Expected Behavior

(see above)

Install Method

Self-Compiled

What version of WLED?

WLED 0.16.0-alpha (2506160)

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions