After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734740 - Antialiasing not always correctly overflown to next cell
Antialiasing not always correctly overflown to next cell
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.37.x
Other Linux
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-13 20:06 UTC by Egmont Koblinger
Modified: 2018-10-06 20:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot (14.85 KB, image/png)
2014-08-13 20:06 UTC, Egmont Koblinger
Details

Description Egmont Koblinger 2014-08-13 20:06:32 UTC
Created attachment 283324 [details]
Screenshot

Using the Monospace 8 font (6x13 pixels), type W, w, M, m letters at the prompt, followed by other letters or space.

Notice that when an 'M' or 'm' is followed by a space, the right hand side of that letter is usually not properly updated, the antialiased cyan column does not get painted. It's not there either if the blinking cursor is in the following cell and it's currently in the invisible phase. The character gets properly updated on focus in/out. It's also displayed correctly if it's followed by a regular character rather than a space. Also, the buggy behavior seems to only arise if there's nothing immediately above the given character.

Interestingly, the same problem doesn't occur with 'W' or 'w', they are always displayed correctly.

See screenshot. The black boxes are there only to see the grid. The letters 'W', 'M', space and dot were typed from the keyboard one by one, and the line terminated by pressing Ctrl+C.

Magnification was done with xzoom, a not-well-known utility similar to xmag but with continuous updating, really useful to examine vte's behavior.
Comment 1 Behdad Esfahbod 2014-08-13 20:12:00 UTC
Thanks for the tip on xzoom!

It might be the case that cairo is not returning correct ink bounds to pango / us, don't remember.
Comment 2 Egmont Koblinger 2014-08-13 21:17:49 UTC
Interestingly, if you start a "cat" and there you type "m m ", backspace over them, type "m m m m ", backspace them etc., in the positions that were already occupied the m's are painted correctly, but as soon as the cursor advances to or beyond the position it reached previously, m's start becoming incorrect.

So it seems there's a difference between the rowdata containing a space, or finishing at the current cursor position. Sending a \e[K from another terminal to this one clears the characters to the right, so newly typed "m "'s will be incorrect again.

In the mean time, VTE_DEBUG=updates always shows the same, the right hand side of the letter 'm' is always repainted (flashes up with red), but is repainted incorrectly sometimes.
Comment 3 Egmont Koblinger 2018-10-06 20:26:19 UTC
This was fixed in https://gitlab.gnome.org/GNOME/vte/issues/26.