investigate strange behavior in stacking tests

[dankamongmen]

See #1068 and #1317 for background info. I've added some Stacking unit tests which verify transparent blitter stacking on quadblitters. It appears that the first plane alone is generating a full block, as opposed to the crossed quadrant we would expect. As a result, our unit test is invalid. Add a new ncvisual_from_rgba() unit test checking this case, and it ought break. Fix the breakage.

[dankamongmen]

hrmmm, we have plenty of NCBLIT_2x2 ncvisual_from_rgba() unit tests. I think the problem in the Stacker tests is something else.

[dankamongmen]

htole(0xffffffff), htole(0xff000000), htole(0xff000000), htole(0xffffffff) results in the expected cross, but replacing htole(0xff000000) with htole(0) gets us a full block...i don't understand that?

[dankamongmen]

are we sure qtrans_check() is right for the ▚ glyph?

[dankamongmen]

are we sure qtrans_check() is right for the ▚ glyph?

nope, this looks right, and is checked by unit test

[dankamongmen]

with that said, i'm pretty sure ncvisual_from_plane() does not work with NCBLIT_2x2.

[dankamongmen]

is the ncplane* n_ coming in with a full block?!?

[dankamongmen]

Sure enough, we're getting a full block in the n_ plane somehow, and ncplane_erase() doesn't eliminate it...does it possibly have a base cell? I don't understand what's going on here.

[dankamongmen]

yeah, it definitely seems to be coming in from the previous test somehow. changes made there, colorwise, are reflected....

[dankamongmen]

ncplane_at_yx() verifies ▚ at top[0, 0]. is this possibly related to #1314? is there possibly an error early in the rasterizer?

[dankamongmen]

our channel from the ncplane_at_yx_cell() is c1ffffff60000000

[dankamongmen]

OK, i circled back around to this, and the StackedQuadCrossed unit test, when modified as outlined earlier, no longer generates an early full block, but instead the expected cross. I'm guessing this got fixed by some of the other stacking work. Closing as fixed.