I'm having trouble understanding this question — any thoughts on how we might be able to clarify it?

I think your last comment "Try writing something of the form.." was good. I also voted to close because as written, it seems ambiguous. Someone could assume a particular potential interpretation the question, answer accordingly & footnote it with "if you didn't mean the interpretation used here, edit to clarify".

But that request has already surfaced in the comments a couple of times. Short of something that demonstrates how the Q is ambiguous, my hot take is that it's on the poster.

Or perhaps instead of an attempted answer, a "let's continue this in chat".

first render-able attempt at converting my scanline rasterizer / renderer to barycentric:

follow up attempt:

I think I'm making the wrong sort of 'progress' here.

Neat! Huhhh, I wonder what would cause artifacts like those...

@DMGregory They have deleted their previous question about the same topic. If the delete and repost, not sure what would be an appropriate step..

@Pikalek I see a happy dancing palm tree.

The first error has something to do with the 4x at a time optimizations & the masking. Above is a single triangle rendered w/ both approaches & then overlaid & ghosted for comparison. The ghost is the expected result.

I went back & wrote a 1x pixel at a time version & that gave me a 1 to 1 match between the barycentric & scanline.

In the 2nd error, I took my programmer's intuition about where the error was & while the edge walking seems to be a better match when zoomed out, a closer look shows there's a lot of miscalculations in the gradient shading.

Given that my math appears good for pixel at a time, my plan is to rewrite the 4x version based off of that. Previously, I was trying to jump myself directly to the 4x version. It would seem that trying to internalize that & the barycentric approach at the same time, along w/ porting the code (the explainer I was looking at was using some flavor of C++) was just a bit too much for me to juggle all at once.

It looks like C# has a separate SIMD library that I'll need to bolt on if I want to squeeze the extra cycles out of this, so I would have needed to rewrite it anyway.

@Vaillancourt Yeah! It often surprises me how some of the merge rules make such organic looking output.

This one was "merge to largest". Each cell is visited in a somewhat random order & it gets merged to the neighboring cell w/ the largest area.

It occurs to me that I should try some variants of that - ordering them smallest to largest, semi ordered, etc.