Orca's segway wheel is temporarily left behind

[j4james]

• LANG="C.UTF-8"
• TERM="xterm-256color"
• notcurses version 2.3.17 (built from commit f24a727ac2e1f0cc0b0ad6d1adc41cd9073514e8)
• XTerm build 368

When running the notcurses-demo intro, as the Orca disappears, the segway wheel is left behind briefly.

This was running at 80x34, which I realise is smaller than the recommended 80x45, but that was the largest I could fit with XTerm's font size set to "huge" (10x20 pixels), which I think is key to reproducing this.

On my Windows console (which always uses a cell size of 10x20) I can reproduce this at a screen size of 80x45. The first height at which is does work correctly is 80x47, so maybe the solution is just to up the recommended size for the demo! I'm curious why it's going wrong though.

I should also be clear that it's very briefly visible on XTerm. I only really noticed because on my Windows console it lingers for about a second - possibly because the frame rate drops at that point. I'm not ruling out bugs in my code being an issue, but the fact that I could reproduce this in XTerm (at least to some extent) suggests that it may be a notcurses bug.

[dankamongmen]

sacre bleu! this looks a great deal like #2076, which would confirm that it is not a wezterm problem.

[j4james]

In case it helps, this is a screen shot from my Windows console at 80x45:

[dankamongmen]

loving these fantastic bug writeups from you, @j4james ! btw if you ever want to slow down notcurses-demo, all of its artificial delays are keyed off the -d parameter. the default value of -d is 1.0. you can scale it as large as you'd like; -d0 eliminates all artificial delay; -df where 0 < f < 1 speeds it up to the limiting case of -d0.

[j4james]

sacre bleu! this looks a great deal like #2076, which would confirm that it is not a wezterm problem.

I did see that, but I didn't think it was the same thing. That looked like it had to do with the info box overlapping the image, which isn't a problem here. But you'll know better than me what the code is doing, so maybe it is the same underlying cause.

btw if you ever want to slow down notcurses-demo, all of its artificial delays are keyed off the -d parameter.

Thanks! That would have been fantastically helpful when I was trying to get that XTerm screenshot. 😄

[dankamongmen]

sacre bleu! this looks a great deal like #2076, which would confirm that it is not a wezterm problem.

I did see that, but I didn't think it was the same thing. That looked like it had to do with the info box overlapping the image, which isn't a problem here. But you'll know better than me what the code is doing, so maybe it is the same underlying cause.

may be different, might not, might be to a degree. certainly i'd rather have your report than not--don't read my reply as a "look through the bugtracker, stupid" even a bit. just a note to myself.

[dankamongmen]

this is interesting. take a look at this blown-up section:

i don't think the tire is cutting low, as it does in wezterm's #2076, but instead it looks like the cells containing the text "frames per semisecond" (and probably those to the left) are....lifted? there are several pixels of black underneath the glyphs, and the maroon background rises above the cell line. the tire seems to be coming down exactly as far as it should.

i mean, its presence there at all is wrong. but this is very odd behavior...

[dankamongmen]

also, we have no other occlusion from the tire, whereas in wezterm it's blocking the HUD and some other stuff.

[j4james]

the cells containing the text "frames per semisecond" (and probably those to the left) are....lifted?

I think that might just be an XTerm bug. It's certainly got nothing to do with your sixel rendering because I can see the same thing with sixel disabled. It also only seems to happen with the "huge" font, so maybe it's got something to do with scaling (based on the quality of the output, it doesn't look to me like that font was designed for that resolution).

[dankamongmen]

alright, well if we leave aside that small oddity, things look very clean aside from the wayward tire. that points pretty clearly at a wiping failure. since there's nothing on top, and we're moving, that points not at sixel_wipe() but at sixel_scrub(). in particular, it looks like we're not damaging all the cells from which we're moving. and i don't think this has much if anything to do with #2076.

in alacritty, we see 4x orca (in their entireties, however), and that similarly has been pointing at a scrub failure.

alright, let's go check that out.

[dankamongmen]

hey @j4james what's your cell-pixel geometry when you reproduce this in XTerm? this can be acquired from notcurses-info:

34 rows (32px) 80 cols (16px) 1088x1280 rgb+256 colors
         ^^^^           ^^^^

[dankamongmen]

i am now reproducing in XTerm, yay:

notcurses 2.3.17 on XTerm 368
40 rows (17px) 80 cols (8px) 680x640 rgb+256 colors

[dankamongmen]

so the part that's left is the leftmost position, i.e. the final one seen before she goes away. font size is "Tiny", not "Huge" as @j4james was reporting, so yeah i think it's a factor of (a) total height in pixels and (b) cell-pixel geometry. indeed, i bet if we plotted the failure across those three dimensions, we'd get a convex polyhedron. so this has got to be a failure to damage, right?

[j4james]

Sorry, I meant to follow up here to say I had seen it again at a different font size when I was playing around with the delay option. I can't remember the font size now, but the part that was left behind was much larger than my original sighting - more like what you're seeing - so it may well have been the tiny font.

The dimensions for the original sighting were 34 rows (20px) 80 cols (10px).

[dankamongmen]

Damaging 25/57? Damaging 25/58? Damaging 25/59? Damaging 25/60? Damaging 25/61? Damaging 25/62? Damaging 25/63? Damaging 25/64? Damaging 25/65? Damaging 25/66? Damaging 25/67? Damaging 25/68? Damaging 25/69? Damaging 25/70? Damaging 25/71? Damaging 25/72? Damaging 25/73? Damaging 25/74? Damaging 25/75? Damaging 25/76? Damaging 25/77? Damaging 25/78?

yeah we ought be damaging well below that. but this matches up with everything we're seeing -- a sharp level at which we don't scrub the graphic below.

[dankamongmen]

YY: 19 p->dimy: 40 s->dimy: 18

s->dimy seems small here? ought be 31...

Sprixel 3507461 (0x560c5322f3c0) 65567B 31x38 (516x300) @8/1 state: 5
44444444444422224444444444444444444444
44444444444220002444444444444444444444
44444444442200002244444444444444444444
44444444422000000244444444444444444444
44444444420000000024444444444444444444
44444422220000000022444444444444444444
44442200000000000002244444444444444444
44220000000000000000224444444444444444
22200000000000000000024444444444444444
22222220022000000000002222222222222444
44444422242000000000000000000022222444
44444442222200000000000000222244444444
44444444222220000000000002244444444444
44444444442222000000000002444444444444
44444444444222220000000000244444444444
44444444444422222000000000022444444444
44444444444444222220000000002244444444
44444444444444422222200000000224444444
44444444444444442222422000000022444444
44444444444444444222222000000002244444
44444444444444444220000000555555556666
44444444444444442200000000555555555566
44444444444444442000000000555555555556
44444444444444422000000000555555555556
44444444444444420000000000555555555555
44444444444444420000000000000000000002
44466666666666665555555555555555555556
44466666666666665555555555555555555556
44466666666666666655555555555555555566
44466666666666666665555555555555556666
44466666666666666666666655555666666666

[dankamongmen]

oh wait that's probably the greatscott banner

[dankamongmen]

yeah we're never actually hitting sixel_scrub() at all for the orca?!?

[dankamongmen]

no, we hit it...

[dankamongmen]

sixel_scrub:887:srubbulous 5672986 state 4 at 8/1 (31/38)                                                                    
YY: 8 p->dimy: 40 s->dimy: 31                

[dankamongmen]

whoa....

sixel_scrub:887:srubbulous 5672986 state 4 at 8/1 (31/38)                                                                    
YY: 8 p->dimy: 40 s->dimy: 31   
...
YY: 9 p->dimy: 40 s->dimy: 18    

!!!!

[dankamongmen]

oh shit, right:

      struct crender *r = &p->crender[ridx];                                                                                 
      if(r->sprixel){                                                                                                        
        s = r->sprixel;                                                                                                      
      }                        

we don't want that persistent across the loop, erp! argh!

[dankamongmen]

before:

303 renders, 51.33ms (77.42µs min, 169.39µs avg, 2.14ms max)                    
303 rasters, 10.42ms (13.28µs min, 34.39µs avg, 40.39µs max)
303 writes, 2.09s (21.38µs min, 6.90ms avg, 64.76ms max)
3.90MiB (9B min, 13.17KiB avg, 571.14KiB max) 0 inputs
0 failed renders, 0 failed rasters, 0 refreshes, 0 input errors
RGB emits:elides: def 7:259 fg 20154:48546 bg 15866:53099
Cell emits:elides: 68965:1866460 (96.44%) 97.37% 70.66% 76.99%
Bitmap emits:elides: 12:284 (95.95%) 3.15MiB (80.93%) SuM: 0 (0.00%)

after:

303 renders, 53.68ms (79.19µs min, 177.17µs avg, 2.11ms max)                    
303 rasters, 10.88ms (13.10µs min, 35.92µs avg, 43.84µs max)
303 writes, 2.00s (21.32µs min, 6.60ms avg, 62.33ms max)
3.90MiB (9B min, 13.17KiB avg, 581.98KiB max) 0 inputs
0 failed renders, 0 failed rasters, 0 refreshes, 0 input errors
RGB emits:elides: def 7:259 fg 20186:47581 bg 16037:51995
Cell emits:elides: 68032:1867394 (96.48%) 97.37% 70.21% 76.43%
Bitmap emits:elides: 12:283 (95.93%) 3.15MiB (80.92%) SuM: 0 (0.00%)

so that tracks. i think that gets it. let me do some testing...

[dankamongmen]

thanks bunches for the report, @j4james; you ought find the issue resolved.

[j4james]

Yep. I can confirm it's working for me now. Thanks!