flat assembler
Message board for the users of flat assembler.

Index > IDE Development > Garbage when scrolling

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
LostCoder



Joined: 07 Mar 2012
Posts: 22
LostCoder
Vertical scroll produces garbage with bold Courier New font. Size is 10.

Image
Post 24 Apr 2012, 19:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
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?
Post 24 Apr 2012, 21:44
View user's profile Send private message Visit poster's website Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler
Same here, the letter m seems to be leaving two pixels behind.
Post 24 Apr 2012, 22:57
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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 Wink).
Post 25 Apr 2012, 08:41
View user's profile Send private message Visit poster's website Reply with quote
SFeLi



Joined: 03 Nov 2004
Posts: 140
SFeLi
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.


Last edited by SFeLi on 25 Apr 2012, 11:33; edited 1 time in total
Post 25 Apr 2012, 10:06
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 25 Apr 2012, 10:19
View user's profile Send private message Visit poster's website Reply with quote
dancho



Joined: 06 Mar 2011
Posts: 74
dancho
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...
Post 25 Apr 2012, 10:21
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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)
Post 25 Apr 2012, 10:30
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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:
Code:
    invalidate:
        push    ecx edx
        lea     eax,[rect]
        dec     [rect.left] ; add this instruction
        invoke  InvalidateRect,[hwnd],eax,FALSE    
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?
Post 25 Apr 2012, 10:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
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.
Post 25 Apr 2012, 10:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 25 Apr 2012, 10:53
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
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.
Post 25 Apr 2012, 11:27
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
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.
Post 25 Apr 2012, 11:32
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
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.
Post 25 Apr 2012, 11:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.

revolution wrote:
Besides, for computers now days even the naive redraw of the entire screen is usually rapid enough to be unnoticeable by the user.
Up until recently I was still using fasmw on Pentium 60 MHz machine. And I may still want to do it in future. Wink
Post 25 Apr 2012, 11:52
View user's profile Send private message Visit poster's website Reply with quote
LostCoder



Joined: 07 Mar 2012
Posts: 22
LostCoder
revolution wrote:
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?
Sorry for that.
Tomasz Grysztar wrote:
how do I know that it will never be off by two pixels?
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.
Post 25 Apr 2012, 12:20
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
fasmw is using GetTextExtentPoint32, which supposedly already contains the tmOverhang:
MSDN on TEXTMETRIC wrote:
The tmOverhang member enables the application to determine how much of the character width returned by a GetTextExtentPoint32 function call on a single character is the actual character width and how much is the per-string extra width. The actual width is the extent minus the overhang.
Post 25 Apr 2012, 12:33
View user's profile Send private message Visit poster's website Reply with quote
LostCoder



Joined: 07 Mar 2012
Posts: 22
LostCoder
Hmm, than it is probably ABC:
MSDN Remarks on ABC wrote:
The total width of a character is the summation of the A, B, and C spaces. Either the A or the C space can be negative to indicate underhangs or overhangs.
In that case A field should be negative on "m" letter.
Post 25 Apr 2012, 12:41
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 25 Apr 2012, 12:49
View user's profile Send private message Visit poster's website Reply with quote
LostCoder



Joined: 07 Mar 2012
Posts: 22
LostCoder
Courier New is TrueType font.
Post 25 Apr 2012, 12:54
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.