GNOME Bugzilla – Bug 333157
Rendering bug on some characters
Last modified: 2007-03-20 20:54:57 UTC
Since I've upgraded to 0.11.18 (and continuing with 0.11.20) I've noticed a slight rendering bug in my terminals with certain characters. I'm using the Bitstream Vera Sans Mono font, and the terminal color is gray-on-black. If I type an ampersand (&) in my terminal[1], and then two more[2], the first ampersand loses its "tail". If I type several ampersands in a row[3] (all but the last one having lost its tail) and then type backspace all of the tails reappear[4]. I'll attach xmag screenshots for 1-4.
Created attachment 60507 [details] [1] single ampersand
Created attachment 60508 [details] [2] 3 ampersands
Created attachment 60509 [details] [3] several ampersands
Created attachment 60510 [details] [4] several ampersands, after pressing backspace once
Bleh, I am an idiot and messed up the two mime types for #2 and #3; they're both pngs though.
Hi Joe, Welcome to the land of vte misrendering :). This is really hard stuff. I'll try to come up with a fix though.
*** Bug 332838 has been marked as a duplicate of this bug. ***
The solution seems to be rendering the glyphs to the left and right of the clip region. This also happens about characters on top and bottom rows (for underlines for example), but that's less noticable.
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/vte/+bug/33144
Created attachment 80741 [details] [review] Draw cells either side of invalidated region (but first apply a clip) This uses the approach Behdad suggests, but clips the right column(s) of the bold font. WIP.
Nice. Have you measured its performance impact? (We really need a performance suite.) Any idea how to do it for top and bottom too? It may be enough to do the top only. It only can happen with underlines (or insane fonts).
Single run of a hexdump suggested that setting a (redundant) clip box was insignificant. No thorough analysis though. As for top and bottom, can we not just draw the lines above and below and allow the clip to take care of the suplus? The misrender of the right hand column of the bold font is not an artifact of this patch, but rather the tight invalidation. I hope it is not a new one!
The patch caused some artifacts where the first column is not redrawn. Best seen in vim, doing page-up/page-down, I sometimes see the '#' from a "#define" in the previous page to remain on the screen.
Ah, that one. That stems from my imperfect understanding of which *"!"£!£ cells one has to include to actually have them redrawn. I'm learning slowly... though I suspect those occassional 1s should actually be cell->columns.
(In reply to comment #14) > though I suspect those occassional 1s should actually be cell->columns. Or cell->fragment. cell->columns is only set on the first cell of a char. The second cell, if any, has cell->fragment set. And there are no more than two cells.
r1548: 2007-01-26 Chris Wilson <chris@chris-wilson.co.uk> Bug 401082 – double-draw issue The main cause of this bug was not expanding the cleared area to cover all the cells affected by the draw and forgetting to offset the clear by VTE_PAD_WIDTH. To counter the performance hit due to the expanded repaint area, each backend is presented with the opportunity to apply a clip to the exposed region before painting. This also fixes bug 333157, * src/vte.c: (_vte_invalidate_cells), (vte_terminal_paint_area), (vte_terminal_paint): * src/vtedraw.c: (_vte_draw_clip): * src/vtedraw.h: * src/vteft2.c: (_vte_ft2_end), (_vte_ft2_clip): * src/vtegl.c: * src/vtepango.c: (_vte_pango_clip): * src/vtepangox.c: (_vte_pango_x_clip): * src/vtexft.c: (_vte_xft_clip), (_vte_xft_draw_text):
*** Bug 418324 has been marked as a duplicate of this bug. ***
*** Bug 420699 has been marked as a duplicate of this bug. ***