gfx_FloodFill 0xFF Freezes

[merthsoft]

I have the following code:

#include <graphx.h>
#include <stdlib.h>
#include <ti/getcsc.h>
#include <ti/screen.h>
#include <sys/rtc.h>
#include <sys/lcd.h>
#include <sys/util.h>

int main(void)
{
    gfx_Begin();
    gfx_SetDrawScreen();

    int points[6] = {
        160,  1,  // (x0, y0)
        1,  238,  // (x1, y1)
        318,238,  // (x2, y2)
    };
    int num_points = 3;
    gfx_Polygon(points, num_points);
    
    srand(rtc_Time());
    while (!os_GetCSC()) { 
        uint8_t c = random() & 0xFF;
        gfx_FloodFill(100, 100, c); 
    }

    gfx_End();

    return 0;
}

If you run it for long enough, the calculator eventually freezes. If I replace the core loop with just:

uint8_t c = 1;
while (!os_GetCSC()) { 
    gfx_FloodFill(100, 100, c++); 
}

A freeze never occurs.

Edit to add: I haven't tested in hardware, only cemu.

[myclevorname]

#include <graphx.h>
#include <stdlib.h>
#include <ti/getcsc.h>
#include <ti/screen.h>
#include <sys/rtc.h>
#include <sys/lcd.h>
#include <sys/util.h>

int main(void)
{
gfx_Begin();
gfx_SetDrawScreen();

int points[6] = {
    160,  1,  // (x0, y0)
    1,  238,  // (x1, y1)
    318,238,  // (x2, y2)
};
int num_points = 3;
gfx_Polygon(points, num_points);

gfx_FloodFill(100, 100, 0xFF); 

gfx_End();

return 0;

}

[merthsoft]

It looks like this is sufficient:

gfx_Begin();    
gfx_FloodFill(100, 100, 0xFF); 
gfx_End();

[merthsoft]

After further testing of the initial code, it doesn't actually freeze. I tried dethrottling CEmu, and it will eventually keep going.

[calc84maniac]

Does this happen in v12.1 of the clibs or on nightly? I did touch the flood fill code somewhat recently when I fixed some clipping bugs, so it's possible something was introduced then.

[merthsoft]

I just tested with v12.1 and it happens.

[myclevorname]

This also happened in the nightly.

[calc84maniac]

Okay, my guess is that there needs to be a simple check at the start of the routine for whether the old and new color are the same (in which case, it should just immediately return because the flood fill operation is a no-op). I'm guessing the flood-fill algorithm assumes different colors, which is causing it to run incredibly slowly when they're the same.