sixel rebuilding is broken since second pass change #2603
Comments
dankamongmen
added
bug
|
ok, debugging of |
|
ok, i've got us up through the actual encoding restore -- we have the two critical loops that walk the auxvec within our band, and i've tested them pretty thoroughly. i've also worked out some lingering issues in auxvec construction over in the downer here is that i've introduced a p^2 (worst-case) algorithm to restoration =. this won't fly, obviously, but i'm hoping mosaics will render it moot. improving it will be tough, though there are definitely a few simple things we can throw in to improve the average case dramatically. that worst-case is difficult to work around with our new sparse scheme, though. i think we'd need to keep copies of the unexpurged band vectors. let's hope it doesn't come to that. |
|
oh actually we could do it in O(P) time and O(C) space by just doing each auxvec entry by itself, and not looking for others. we'd need the O(C) space to keep an index into potentially each color's buf, or else we're right back to O(P*E) on encoding length E (and this would be an average case, not a worse case). well, let's keep that in our back pocket. |
|
also, valgrind is warning about an uninitialized element of the |
|
finishing this up in the |
|
alright, we're copying in the rest now, and are almost there. we get some crud in the rebuild:
if i write color 0 to all elements of the auxvec, it improves, but is not perfect:
so there's almost certainly an issue in the reload calculations. let's test with them all hardcoded to 0 and see if that at least blacks everything out. if it does, our problem is in |
|
nope, we get the same essential pattern hardcoding 0s in |
that's on a 23-high cell. we ought be getting 4 more rows restored for this cell, no? 23 * 19 == 437. but 438 % 6 == 0. so 1 row is indeed all we should get from band 72. we ought be getting four from band 76/ |
|
better!
|
yeah that looks right now. it looks like we're still missing a (more regular now) periodic pixel row... |
if that's |
that's fixed, but now the second ought show 1, and it's instead showing 0. indeed, this loops back on itself after 110, and is almost certainly responsible for our pattern. |
|
alright, we now get an all-solid pattern when i handset |
|
writing all 0s from |
|
hrmm, no, even when writing all 0s, we get some of the following in restore: so our problem is presumably there. |
|
ahhh, found it! we now get blocks from wipe...and that ought resolve it all.... |
|
very close! this is without any artificials
|
|
ok, we no longer have any gaps, but things are a bit blockier than they ought be. still a regression, but a small one! closer! |
|
ok, i've got a good lead on this last bit of brokenness: if i fake the auxvec to be all 65535 (transparent) through the first 6 pixels of the (11px wide) cell, and color 0 through the rest, everything is transparent. if i reverse that, everything is black. i've verified the mix via output, so it seems that perhaps we're pulling from one side or the other to rebuild? ugh. |
|
similarly....if i tag even columns with 0 and odds with 65535, we get all black. if i invert that, we get all transparent. how does that work with the previous one? are we perhaps pulling everything from a single column? that would explain the blockiness! |
|
and with srand(time(NULL));
int add = rand() % 2 ? 1 : 0;
for(int y = 0 ; y < tp / x ; ++y){
for(int x0 = 0 ; x0 < x ; ++x0){
uint16_t color;
memcpy(&color, &auxvec[(x0 + y * x) * 2], 2);
fprintf(stderr, "%03d ", color);
color = ((x0 + add) % 2) * 65535;
fprintf(stderr, "FAKING COLOR %hu\n", color);
memcpy(&auxvec[(x0 + y * x) * 2], &color, 2); we get one or the other about half the time. it's gotta be pulling from a single column. fucker. |
|
YEP |
|
yep, we work now =] W00T. |
|
i believe our complete sixel pipeline to be working once more, with the new sparse, multithreaded system. let's cut 3.0.6. |
Issue #2573 brought substantial speed gains, but also left sixel rebuild in a nonfunctional condition. I'm pretty sure we're building up the auxvec correctly in
sixel_wipe(), but we need adaptsixel_rebuild()to the new data arrangement. Currently, rebuilding simply has no effect (except on the TAM); this can easily be seen in[intro], when the orca is to the left of the HUD.We need to fix this before we can release 3.0.6.
The text was updated successfully, but these errors were encountered: