Background erase behavior changed in SCRT 6.1.1

[FuzzyFox]

I just upgraded from SCRT 6.0.3 to 6.1.1, and noticed a change in rendering behavior. The "clear to end of line" ANSI sequence appears to clear using blank spaces in the default background colour, rather than the current background colour. Here is a quick example:

In a terminal window:

echo -e '\033[31m\033[44m hello \033[K\033[m'

In the latest version of SCRT, you get the word "hello" in red with a blue background.

In previous versions of SCRT, you get the same, but the blue background extends all the way to end of the line, rather than stopping right after 'hello'.

I have some ncurses programs that depend on this rendering behavior in order for the screen to look right. It seems like a regression, to me.

[rtb]

Hello FuzzyFox,

Thanks for bring this to our attention. I have been able to reproduce this and have notified our development team.

As I have any updates on this situation I will post to this forum thread.

If you would like to be contacted directly, please send us your contact information Here

[rtb]

Hi FuzzyFox,

We have a newer build of SecureCRT that may resolve this issue.

If you would like to test it, send us a note here referencing this forum thread #3224, and whether you need the installer for SecureCRT only or the combined SecureCRT/SecureFX installer.

[FuzzyFox]

The newer build that I am testing resolves the problem I reported, but there remain some rendering problems that I did not realize before. They are all, however, related to background-erasing.

Upon re-testing my application, I noticed that it also makes use of a different VT220 escape, ESC [ n X, which simply erases characters from the current cursor position.

The VT220 has a whole class of "erase" functions, to whit:

erase to EOL        esc [ K
erase to EOL        esc [ 0 K
erase to BOL        esc [ 1 K
erase line          esc [ 2 K
erase to end screen esc [ J
erase to end screen esc [ 0 J
erase to begin scrn esc [ 1 J
erase screen        esc [ 2 J

delete char         esc [ * P
insert line         esc [ * L
delete line         esc [ * M
insert char         esc [ * @
erase char          esc [ * X

Each of these has the potential to erase characters from the screen, and when doing so, I believe the correct behavior (and the behavior of older versions of SecureCRT) is to erase those characters using the current background colour). The internal build fixes the ESC [ K function, but I noticed that ESC [ J does not erase the screen using current background, nor does ESC [ X erase characters using the current background.

[FuzzyFox]

Just to make this clear:

echo -e '\033[31m\033[44m\033[2J hello \033[m'

The above should cause the entire screen to turn red, with the word 'hello' in blue.

echo -e '\033[31m\033[44m hello \033[14X\033[m'

The above should cause the word 'hello' to be followed by 15 red spaces.

There may be other combinations and permutations of erase sequences that might yield incorrect behavior, but I imagine your engineers can find the root of this problem.

[rtb]

Hi FuzzyFox,

Thanks for the update!

I received your email and I have updated our development database with this valuable information.

Should we have further questions or build testing requests, I will contact you via the email address we have on record.

[FuzzyFox]

I imagine by now you think I'm beating a dead horse, but here is another rendering change that I thought I would bring to your attention:

The following escape sequence should "reverse" the screen:

echo -e '\033[?5h'

In older versions of SCRT, this causes the entire screen to invert, that is, foreground and background are reversed, no matter if a character has been printed in every location, or not.

In the new version of SCRT, though, the only characters that are inverted are those that have been actually printed to the screen. On parts of the screen that have not been printed on, the colours do not change. I feel that this latter behavior is incorrect; the entire screen ought to reverse, since this has a better cosmetic effect.

I mainly noticed this behavior because I use the option "Visual Bell" which causes the screen to briefly reverse whenever ^G is printed. However, in the new version, the whole screen doesn't "flash" as a result; only the characters printed so far onto the screen will "flash"; it doesn't really look as good as it used to.

[rtb]

Hi FuzzyFox,

Thanks for the update!

I have updated our development database regarding the painting issue with this information.

Should we have further questions or build testing requests, I will contact you via the email address we have on record.

[FuzzyFox]

The latest test build from your developers resolves all of the issues I've reported here. Looking forward to the next release.

[rtb]

Hi FuzzyFox,

Thanks for letting us know that all is resolved with regards to the way that SecureCRT was painting the screen.