Questions about multisize.six

[j4james]

I've just been testing your multisize.six and enigma.six images in my terminal. I knew you could use multiple aspect ratios to alter the DECGNL movement, but I wasn't aware they could also be used to output sixels with different sizes. Those examples are really cool! And I did manage to guess the enigma one before testing it. That was an interesting challenge.

But what I wanted to ask you was whether you also got an extra blank line on your VT340 which causes the top line of the multisize.six flag to scroll off screen? If I clear the screen first (i.e. clear; cat multisize.six) it works fine. However, if I don't start at the top, so it's forced to trigger a scroll, then it ends up scrolling too much. So I get something like this:

I know why it happens in my terminal, because it's something I do deliberately to match the VT340 behavior we investigated in issue #11. However, I figured if you were also seeing that blank line, you would likely have added something like \e[H to the image to avoid that. Since you didn't, I'm wondering now if I've actually got this behavior wrong.

The other question I had was why are you including the third and fourth parameters in the raster attribute commands? After the first DECGRA you immediately fill the entire screen in red, so any background fill would be overwritten anyway. I would have thought you could just leave off those parameters entirely. Does it make any difference on the VT340?

[hackerb9]

I'm pretty sure it worked with scrolling, but I'm out of town for at least the next week and can't test my VT340. The extent parameters (Pn3 and Pn4) may have prevented the extra blank line. I'll have to check when I get back.

---

When I created enigma.six, I was thinking you were probably the only person in the world who would solve it. 😊

[j4james]

I'm pretty sure it worked with scrolling, but I'm out of town for at least the next week and can't test my VT340.

OK, no problem. It's not a priority for me at the moment. I might experiment with some other approaches and see if I can find a better algorithm, but I'm honestly quite happy it worked as well as it did!

[hackerb9]

Just verified on my VT340 and the top line does not scroll off no matter if the screen is cleared or not.

The other question I had was why are you including the third and fourth parameters in the raster attribute commands? After the first DECGRA you immediately fill the entire screen in red, so any background fill would be overwritten anyway. I would have thought you could just leave off those parameters entirely. Does it make any difference on the VT340?

You are correct that the extent parameters (Pn₃ and Pn₄) are completely optional. However, specifying them can make images display more quickly since omitting them still fills the background but with an infinite extent. Of course, fastest would be using a transparent background which would work identically for this particular image, but part of what multisize.six tests is if emulators correctly overlay "opaque" sixels of different aspect ratios.

[j4james]

Just verified on my VT340 and the top line does not scroll off no matter if the screen is cleared or not.

OK. Thanks for confirming that. I have a theory which I think explains the behavior. Usually when you have a sixel height that exactly aligns with a cell height, it forces the screen to scroll one row more than is necessary to fit that sixel. However, in this particular case, because of the large aspect ratio, your sixel height fills the entire display. Under those conditions, if it scrolled an extra row, the top of the active sixel would be forced off screen, which would make it unusable.

Based on that theory, I've made my sixel implementation clamp the scrolling so it never forces the top of the active sixel outside the margin. That still passes all the existing scrolling tests, and can also display the multisize test without triggering a scroll..

[hackerb9]

I have a theory which I think explains the behavior. Usually when you have a sixel height that exactly aligns with a cell height, it forces the screen to scroll one row more than is necessary to fit that sixel.

That sounds plausible, but we may want to make a specific test of that hypothesis, perhaps a modification of extremeratio.six.

[j4james]

we may want to make a specific test of that hypothesis

If I'm wrong I don't actually want to know! At least for now. I'm just happy that I've got the existing tests working, and I want to focus on getting the code cleaned up so I can create a PR for Windows Terminal. If there are still bugs in the parser, I'll deal with that later. There are actually a number of cases where I've been guessing the behavior that really should be tested, but I don't have time for that now, and I doubt anyone else cares.

Before I forget, though, there was something else I wanted to mention to you about your usage of raster attributes. I know it doesn't really matter to these particular tests, but it looks to me like you're assuming the height gets multiplied by the aspect ratio (e.g. you'll use a height of 6 with an aspect ratio of 80:1, assuming that's going to fill the full screen height). But as far as I understand, the height is specified in screen pixels, so I think you should be using 480 (if that's what you intended), regardless of the aspect ratio.

[hackerb9]

But as far as I understand, the height is specified in screen pixels, so I think you should be using 480 (if that's what you intended), regardless of the aspect ratio.

Could very well be. I'll double check. Right, again! I'll document it.

And congratulations on your huge step forward for Windows Terminal!