Vertical scroll produces garbage with bold Courier New font. Size is 10.

Please give exact steps needed to reproduce the problem. Also which OS and which fasm version? Does the contents of the source code affect things?

Same here, the letter m seems to be leaving two pixels behind.

Please give the details of OS, resolution, graphic hardware.

I tried it on 64-bit Win7 and on 32-bit XP SP3, and was unable to reproduce on either. Unfortunately I no longer have Windows 95 installed to try it on elder system (I reverted the machine I had it on back to MS DOS 6.22, FASMD now rules there ).

Tomasz Grysztar
32-bit Windows XP SP3, 1280x800x32, ClearType turned on, Courier New, Bold, any size (20 on screenshot), scrolling window with a mouse wheel up and down several times.

Hmm, actually I noticed it in WinXP after i turned ClearType OFF. While it was on, the effect was simply not discernible with my contrast settings, at least on smaller font sizes.

Is it possible that some letters have pixels drawn outside their boxes? It seems that the invalidation region I set up is not enough to cover some of the drawn pixels.

win XP 32bit SP3,
1680*1050*32,
dell 2007wfp,
nV GF GTX 260,
driver version : 285,58 whql,
fasmw Courier New, Bold , any size,
same here : vertical scrolls produce red pixels...

Confirmed minor artifacts for bold and italic fonts with and without antialiasing.
IMHO, it is Win32 problem with the wrong width of the characters for bold and italic fonts. It is not related to ClearType (actually with cleartype off the artifacts are plain black and more visible)

Yes, it seems that some of the letters have pixels drawn outside of their boxes, as it is possible to fix it by making invalidation region one pixel wider to the left: But the correctness of such fix is doubtful, because if character can be out of boundaries by one pixel, how do I know that it will never be off by two pixels?

VScroll can be done by copying the lower (upper) section of pixels and moving up (down) the screen and then redraw the new lower (upper) section. Why does VScroll need to know the horizontal width of an individual character? The entire width of the new drawn portion can be erased as one piece before the new text is drawn.

In asmedit's architecture the scrolling is handled internally, so your solution does not apply here in such an obvious way. Remember that it was designed to be working cross-platform, the same code is used for text-mode fasmd, for example, and the same would work for escape-codes-based console, too.

And the problem here comes from the fact that it does not redraw the parts of the line that are supposedly the same as they were before the change. Even if you were simply copying the pixels from one place to the other, still the same thing would occur unless you invalidated the whole window (or the wider area, as in my quick fix).

Since you need to make it cross platform then you could extend the "will be changed" portion by one whole character at each end and then do the scroll.

How would that one additional character be justified in a general design? This is a Windows-specific fix, related to a specific way in which the Windows abstraction layer for asmedit handles the text buffer changes signalized by the core.

One whole character fixes the current problem and has no detrimental effect on any other platforms. It also addresses your concern about "how do I know that it will never be off by two pixels?".

Besides, for computers now days even the naive redraw of the entire screen is usually rapid enough to be unnoticeable by the user.

Such logic should never be put into a core, as core design has to simply reflect the functional view of the system, which can be easily interpreted when you write an interface for it. So even if core was saying that there is some area needed to be refreshed (which is not the case with asmedit, because there determining which characters changed and thus need to be redrawn is left to the abstraction layer), it would have to clearly specify the exact area, otherwise it would be a bad design. It would then be responsibility of OS-specific interface to decide what to do with that data, on different systems different problems might arise - but providing the clear set of rules from the core makes it easier to perform any adjustments necessary in the abstraction layer.

With asmedit, the interface has much freedom - it can simply redraw the whole screen each time, or check what has changed and redraw only these portions - on Windows it also uses the invalidation mechanism for that. It is even possible to add to Windows interface the ability to detect what pixel block can be copied from other portions of the window instead of drawing them anew (like in the case of scrolling), but this wouldn't change anything in case of this problem, as it is related to the dimensions of invalidated region created by Windows-specific interface.

Up until recently I was still using fasmw on Pentium 60 MHz machine. And I may still want to do it in future.

Sorry for that. There is functions GetTextMetrics and GetCharWidth32/GetABCWidth.
Structure TEXTMETRICS contains tmOverhang field which probably one you need. Also my experiments shows that members of ABC structure can be negative, so I can assume that OS character drawing routines calculates offset after drawing, and extent calculation functions can return smaller size of character instead of actual.

fasmw is using GetTextExtentPoint32, which supposedly already contains the tmOverhang:

Hmm, than it is probably ABC:
In that case A field should be negative on "m" letter.

ABC only applies to TrueType fonts.

However, I think that staying with GetTextExtentPoint32 result, but using the negative tmOverhang to extend the invalidation region size may be the right way to do it.

Courier New is TrueType font.