smooth bitmap movement with kitty graphics

[dankamongmen]

Currently, bitmaps can move only a cell at a time. That leads to jerky movement. With Kitty, we can do subcell placement. With sixel, we can fake it by adding transparent rows/columns. Consider doing so.

Actually, this could apply to all blitters. Quadblitter could move in half-cell increments by adding a transparent row or column of source pixels. hrmmmmmmmmmmmM!

[dankamongmen]

note that this isn't just relevant to movement of planes, but also for centering. notcurses-info currently looks like this (see below). i can't get the logo centered, because it's 60 pixels high, on 4x20 pixel high cells. we'd thus want to be halfway into the first row, but that's unavailable, and we're stuck with either the first or second row, 10 pixels away from where we want to be.

[dankamongmen]

yeah we ought definitely do this. i think the API is basically "expose pixel coordinates for ncvisual_render(), and get as close to it as possible". with kitty bitmaps, we can get directly there with no further help. with sixel, we'd need insert the transparencies. with cells, we'd always have to do it manually.

[dankamongmen]

i think it might be better, as mentioned in #2230, to add two new fields to ncvisual_options, pixoffy and pixoffx.

[dankamongmen]

or maybe we'd like a new function, ncvisual_render_bitmap() which is restricted to NCBLIT_PIXEL and uses absolute x,y pixel coordinates...

[dankamongmen]

hrmmm. let's go ahead and add the fields to ncvisual_options (not implemented for now) for #1777's sake. we'll only use it with cells when the offsets are 0 or perhaps half. if we want an absolute positioning function later, we can add one.

[dankamongmen]

so we've got these fields added to ncvisual_options. let's try using them. Kitty support will be trivial, as it allows us to directly specify a cell pixel offset. Sixel will be tougher. Let's create a distinct bug for it, and limit this one to kitty graphics.

[dankamongmen]

so things this will require:

• if offsetx is set, our cellwidth goes up by 1
• if offsety is set, our cellheight goes up by 1
  • these will be reflected in the sprixel cell geometry and the TAM size
• if offsetx >= cellpixx, error
• if offsety >= cellpixy, error
  • maybe not? remember that a font size change could invalidate these conditionals later
• if offsetx and/or offsety, but blitter is not NCBLIT_PIXEL, error
• pass offsetx/offsety down through blitterargs pixel union
• in kitty, when preparing TAM, account for offsets
• in kitty, actual encoded data doesn't change at all, good
• in kitty, add X and Y params in display (a=d) command

[dankamongmen]

i've added the BitmapSmoothMove unit test for this functionality

[dankamongmen]

hrmmmm maybe rather than doing this on a per-blitter basis, we ought just do as suggested in the original filing, and add transparent rows/columns to the source material? that's a lot of extra computation for the pixel blitters, though...nah, i think we'll just have to be badass

[dankamongmen]

smoothmov.mov

[dankamongmen]

alright, well there we go. @kovidgoyal, @wez, thanks for the good protocol; we'll support smooth movement in your terminals upon merge. i'll get to the much more annoying task of sixel smooth movements this week, hopefully. this lay down all the necessary infrastructure, though. sweet!

[kovidgoyal]

You are most welcome!