Hi Eric, > On Jan 17, 2025, at 7:04 AM, Eric Auer via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > > Hi Jerome, > >>> recording in COLOR, the color would be an good candidate for compression; >>> even trivial runlength encoding >>> would probably provide excellent compression ratio as color rarely changes. > > As you apparently already "compress" areas without text, you could just > split processing into text and color and do things similar to before. > > For example, store the color only for the first column first. > > If the whole line is in the same color, you are done. > > If another color starts later, store the color-column pair for that etc.
That is more or less my thoughts as well. Handle color and text separate. Allowing possible RLE compression on each. A current inefficiency (even in mono mode) is when there is a lot of leading whitespace. For example, all spaces with only a single character in the last column. However, that is very rare when using the command line. More common would be a “horizontal rule” style bar of all “-“ or similar characters. Both would benefit from RLE compressing the text. > >> RLE is very simple and easy to implement even in assembly for both encoding >> and decoding. > > Exactly. Even proper RLE is :-) > >> hot-key support to turn on/off logging, perform screen captures and some >> other > > Those would be nice indeed :-) > >> Based on the various methods being used to capture text and the contents... > > That might actually be more complex than a single RLE method would be? I was referring to how LOGGER captures the text. Not how it is being stored. But yes, the methods LOGGER uses to get that text are far more complicated than implementing RLE. It does not simply hook the BIOS TTY or other Text output interrupts. It also monitors screen scrolling, cursor movements, video modes changes and more. It not only get text from interrupt calls put also can pull it directly from video memory. While I would not say it is complicated, capturing that text is a lot more complex than most may realize. > >> a line can consume as little a 2-bytes. > > :-) > >> When given a tiny 256K XMS memory buffer, it can store about 128 color pages > > Tiny is relative, I guess. Yep. 256Kb of 8Mb or more XMS is a tiny amount of memory. 256Kb of your 640Kb base memory is enormous. >> Logger is also very fast... Adding RLE would effect performance. >> However, the effect could be improved speed when logging to XMS. > > I think that your main overhead is the NUMBER of times you access XMS, > not the SIZE of copied contents per call. Those already are small, no? Yes, no, relatively so. The smallest size of data that can be transferred directly to XMS is a 16-bit word. Logger has an internal buffer to reduce the number of transfers to XMS. It has been a while and I would need to go look at the code to be certain. If I recall correctly, that buffer is enough to store 80 16-bit words. This can store 80 or 160 characters (COLOR or MONO mode). LOGGER will send this data to XMS when the buffer is full, when it starts a new line, video mode is changed and in a couple other situations. LOGGER can record longer lines when in other video modes (like VESA 132x50). I just used a buffer size to match the most commonly used video mode. The buffer could be larger and the frequency of transfers could be reduced. That would increase the program memory footprint. Although unlikely, it is possible that too large a buffer could have perceived effects on system performance. > > Cheers, Eric > > There are a lot of improvements that could be made to LOGGER. It gives users something to look forward to if/when there is a newer version. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
