Created attachment 33956 [details]
The screenshot

I can confirm it. I use "Fixed Bold 12" font with LANG=hu_HU (which happens
to be different than the same font with en_US).

Note that the bug also occurs on the bottom of the screen, but it's slightly
harder to reproduce it since it needs a character that uses the topmost pixel
row of the cell (e.g. the vertical line of midnight command copy-pasted to
another file in UTF-8 mode, actually it is U+2502), and then we have to scroll
backwards (e.g. using the scrollbar).

Ohhh, there's a more serious scrolling bug closely related to this one!

In src/vte.c there's a "#define VTE_PAD_WIDTH 1".

If you change it to 0, the 1 pixel border of the original window disappears,
so does the bug. However, the whole window somehow looks uglier IMHO.

Change this number to a bigger one, for example 5 (this number will be used in
my further examples). You'll not only more clearly see the original bug, but
you'll also see buggy content inside the terminal as soon as you start moving
the scrollbar with your mouse. In some of the rows the 5 topmost pixel rows
will simply be missing. Screenshot follows.

If you use the mouse wheel, you can see some logic in the behavior. The mouse
wheel always scrolls a half window. Create a long output, e.g. "ls -l /dev"
in a terminal with even number of rows. Scroll back several windows using the
mouse wheel. The bottom of the window always shows the top 5 pixel lines of the
row that's just been scrolled out. Now slowly start scrolling downwards. At the
fist step these 5 lines are correctly scrolled into the center of the screen,
so the screen is perfect, and the 5 pixel border doesn't contain any noise this
time. Scroll down once again. The bottom 5 black (oh, I mean, background color)
lines are scrolled onto the middle of the screen.
If the terminal has an odd number of lines, this only happens at every second
scroll. For even number of lines this happens at every consequent scroll.

I'm pretty sure that the original bug report and this one are very closely
related to each other and are probably caused by the same bug in the source.

Of course, needless to say, most likely this bug is also present in the default
VTE_PAD_WIDTH=1 case, it is only much harder to notice it.

Created attachment 36038 [details]
my screenshot

Oh, forgot to say: in all the cases the contents of the window is repaired
when it receives an expose event.

Created attachment 36042 [details] [review]
a fix for the problems

Patch attached, tested, works for me, fixes all the issues mentioned in this
report.

There were three errors in the code.

1. Checking whether the topmost character row is being refreshed and hence the
border should also be included in the refresh area was faulty, it checked for
the value of the calculated pixel offset (rect.y) instead of the character row
(row_start).

2. Two vte_invalidate_cells() calls assumed that the 4th argument, the number
of the first row to be refreshed is counted according to the visible screen.
This is not true, the value should correspond to the row number in the whole
text buffer (including the scrollback region) since the implementation of this
functions substracts this number from its 4th argument.

3. Two vte_invalidate_cells() calls that should clear the border after
scrolling (what the original bugreport is about) were completely missing.

Notes:

Even with this patch pixels may flash up for a short time in the border. Just
set VTE_PAD_WIDTH to a large value (e.g. 50) and see it... Probably no-one
will ever notice it with a one-pixel border :-)

These pieces of code try do optimize things by scrolling the whole region of
the window. Since it can only be done with solid backgrounds, obviously a
different piece of code is executed when having a bitmap or transparent
background. That piece of code always redraws the screen, which seemed to be
only a little bit slower than this one. However, that code does not suffer from

any of these problems. So you can even get correct behaviour from vte without
this patch, just create a pixmap of your favorite color and set it as
background, or choose transparent background with maximum opacity.

See also bug #164153.
The patch there obsoletes the second hunk of this patch.

Then this probably also suffers from conflicts with recent patches that were
commited. Could we consolidate the remaining issues into one report maybe?

The first hunk of my patch is still waiting to be applied, and it cleanly
applies to current 0.11.13. The rest is discussed in bug #164153.

I'll try it on for size :-)

I applied this to CVS head and rebuilt and I still see one pixel from the
previous line IFF I scroll down and the line has an underscore char on it. So
applying the first hunk of the patch doesn't seem to fix this entirely...

The proper solution for the 'one pixel off' bug is in described bug #164153.
I don't think this particular small patch (the first hunk) fixes anything on its 
own, but looking at the source it's clearly false (it checks for something that 
is always false, perhaps someone simply mistyped the source, he typed the name 
of one variable while he thought of the other one.) A similar check near this 
one for the bottom of the screen is okay, this is a symmetric case for the top 
of the screen.

Seems to me that with vte-0.11.20 (probably with an earlier version too)
this whole issue is completely fixed now, so this bug can be closed.

Bernhard (the original reporter), do you agree?

Yeah, I've not seen this for quite a while too.

Yes, seems to be fixed here, too.