"xterm -fa FontSpec" (xfreetype) has some flush trouble (making it unusable)

[vallon (Justin)]

cc: maintainer of xterm

Tried using "xterm -fa Courier-12" which uses XFreeType/font-config for font rendering. However, there are drawing/flushing issues. It behaves like an XFlush is missing:

• On the local machine, a new xterm displays a prompt and scroll bars, etc. Typing into the window yield no response, but the input is being processed. If I resize or deactivate the window, the screen updates. If I press return enough times, the screen updates when it scrolls. If I run a command that generates a lot of output, the output is displayed (again, seemingly due to scrolling).
• "ssh linuxhost xterm -fa Mono-12" works fine when displaying back to MacPort X11.app.
• From a linux X11 server, "ssh machost xterm -fa Courier-12" has same flushing trouble.

=> It appears it is MacPorts xterm that is the common factor.

I have removed all xrdb resources to insure it is not sensitive to any of my XResources, with no change in behavior.

$ port installed xterm or Xft2
The following ports are currently installed:
  Xft2 @2.3.3_0 (active)
  xterm @344_1 (active)

[kencu (Ken)]

We recently enabled double buffering and this sounds related to that.

[ThomasDickey (Thomas Dickey)]

A different user commented on this, yesterday and send a proposed fix (for this, and a related problem with the blinking cursor).

[mthorn66]

I believe I am the user that Thomas Dickey referred to. Until now I hadn't established a Github account so that I could comment on these tickets directly.

I have seen similar drawing issues with a recent MacPorts xterm when I use the faceName resource to specify the use of a TrueType font. In my case my typing is not shown until I make the window lose focus and then regain focus again. I verified that my problem went away if I rebuilt the xterm port without configuring --enable-double-buffer, so, yes, I think this problem was caused by the change to add --enable-double-buffer.

As Thomas Dickey writes, yesterday I found a possible fix in the xterm source code for this issue and forwarded it to him. In the process of doing this, I also found that telling xterm to use an underline cursor (-uc) causes xterm to update the display when the cursor is drawn and mitigates much of the problem.

[ThomasDickey (Thomas Dickey)]

I went further, fixed a problem with "-hold" which did not paint the screen for double-buffering, and added a "buffered" resource setting to turn this on/ff. Mike reported a problem with scrolling performance, which (I think) is fixed in my 346o snapshot. I'd just turn it on all the time, but the window border isn't the right color. However the upcoming 347 will fix this bug report.

[ThomasDickey (Thomas Dickey)]

I uploaded 347, which seems to be working reasonably well with double-buffering. (vttest shows me some cases to work on, but most people won't run vttest).

[vallon (Justin)]

347 fixes this for me.

[vallon (Justin)]

This is fixed for me. I do not see a way to mark this ticket as resolved.