hackerb9
Questions about multisize.six
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?
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. 😊
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!
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 (Pn3 and Pn4) 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.
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..
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.
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.
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!
@hackerb9 I've just released a little app that I made for learning nautical signal flags, and I thought you might find it interesting, because I'm now using your multisize raster attributes trick to optimize some of the flags.
I've tested it at 19200 baud, and it actually seems quite usable to me at that speed, but I'm not sure if there are other factors that might make it slower on a real VT340, of if it's just the bandwidth that matters.
Anyway, if you get a chance to try it out at some point, please do let me know if you see anything that looks broken. I'm fairly confident that the Sixel itself is OK, but I'm less certain about the interaction with double-size characters.
This is the repo: https://github.com/j4james/vtinterco
Your signal flag app is fun and right up my alley. Sorry for the delay in testing it out. The machine my VT340 is plugged into doesn't have a C++20 compiler.
Even after compiling, I was having trouble running vtsigint until I figured out that the program is disabling XON flow control. Running stty -F /dev/ttyUSB0 ixon from another terminal mostly fixes it. There are still glitches, however.
Certain flags, such as Yankee, have trouble more often. Since Yankee is one that sends a lot of data, I wonder if it is a communications glitch rather than an error in the double-size character interactions. (Note: I don't normally see communications problems as I'm using a FTDI chip which handles XON/XOFF in hardware.)
- View Alphabet works
- View Numeral works, although the words are mushed together ("Soxisix")
- Test Alphabet usually works, but sometimes one of the colors is shifted 40 pixels left starting at the line with the first double height answer and continues to the bottom.
- Test Numeral usually works, but again, the image can be shifted 40 pixels to the left occasionally. This time the glitch seems to start after the second answer.
- Test Single usually works, but again there is the problem with the flag shifting left part of the way down.
- Test Double always shows the top flag too far to the right.
- Lookup Double has multiple problems. The top flag is shifted to the right (or the bottom is shifted left). After typing the second letter, the Morse code always erases and overlaps the top flag. Typing the second letter clears both the first letter and the entry box. Typing more letters doesn't let one choose other flags; one must hit Backspace twice.
If you could add a Redraw Screen key (Control-L or Control-R?), that would help me figure out if it is always the same error for the same data.
If you also add a MediaCopy to Host key in your program, I'll upload some screenshots for you.
By the way, the program relies on having an Esc key to go back to the previous menu, but the VT340 lacks such a key. I've been using Ctrl-[, but it is a bit inconvenient.
Slight tangent: the Yankee flag takes a noticeable amount of time (almost a second at medium size) to render on the VT340+. Victor and Mike are also noticeable, maybe half a second. The app is still quite usable, but I am curious if there is a more optimal way to draw them.
Thanks for testing and the detailed feedback! I've copied your comment into an issue on my repo (https://github.com/j4james/vtinterco/issues/1) so I can followup some of the points there and not sidetrack this issue too much.
the Yankee flag takes a noticeable amount of time (almost a second at medium size) to render on the VT340+. Victor and Mike are also noticeable, maybe half a second.
Yeah, I would expect those to be the slowest - it's because of the diagonals. Almost everything has to be rendered at a 1:1 aspect ratio, so I couldn't see many opportunities to utilize your multisize trick. But if you have any other ideas for improving the performance, please do let me know.
You can find the current sixel content for all the flags here in flags.cpp. They're in raw C++ strings, so you need to strip the R"( from the front, strip the )", from the back, and then add a sixel wrapper (I'm using \033P9;1q and \033\\).
Although, looking at that file now, the medium Yankee flag is around 950 characters, so at 19200 baud I would have expected around a half second rendering time (assuming the download speed is the limiting factor). So maybe there is more to it than that. But as you say, it should still be quite usable.