mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
When aline adds very long lines of text into a @window, the text is there. It can can be highlighted into the clipboard, and $line(@window,N) finds it, but it does not display on screen once the line reaches a certain length.

I finally figured out that this effect depends on the font+fontsize. It didn't happen in Fixedsys-9, but when I switched to Verdana-9 the last line displayed is 3900. When I increase the size to Verdana-14 it only displays through the 2500 line. Switching to Consolas-14 enables display through the 3250 line. For fonts like Times-New-Roman where Bold has a greater horizontal width, enabling Bold reduces the number of lines that display.

If this alias is edited to make the @window be -l listbox, the same number of lines are visible, and the effect is still there, except the visible text blinks into existence above the invisible lines, once the lines are finished being added to the window.

Code:
alias test_long_lines {
  var %len 1500 , %win @longlines
  window -e2 %win | clear %win
  while (%len isnum 1-4100) {
    aline %win %len $regsubex($str(x,%len),/x/g,$rand($chr(32),Z))
    inc %len 50
  }
}


It doesn't happen for wrapped text from /echo or /aline -p, and it didn't matter whether or not the $rand() range is changed so the line is broken by spaces or not, or is only A-Z.

This happened prior to the beta increasing the Max Line Length Limit.

Edit:

In talking with Racoon about this issue, it seems related to total width of 32767.

//echo -a $width($str(i,3275),Consolas,-14)

There are 7 fonts who report their type is 'raster' instead of 'truetype', and none of them flip to being invisible when they become "too long." But $font(Fixedsys Excelsior 3.01 NoLiga).type is an exception to the truetype fonts, in that it doesn't go invisible when too long.


Last edited by maroon; 19/10/18 08:49 AM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. I was able to reproduce this issue, although for different string lengths to yours. I found an interesting discussion on a similar-sounding issue here. After some testing, it does seem to depend on how long it takes for ExtTextOut to display the text. When using fonts that take more time to display, I see fewer lines, and switching to a faster font, I see more lines. Unfortunately, the solution described on stackoverflow cannot be used by mIRC's display routines, which are more involved, especially when handling Unicode. I have added this to my to-do list for now.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
My thought was that it's a DC max-width canvass issue, and that mIRC might consider truncating canvass widths to something much smaller, like 8192 px wide for non-picture windows. But I'm just guessing.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
My thought was that it's a DC max-width canvass issue, and that mIRC might consider truncating canvass widths to something much smaller, like 8192 px wide for non-picture windows.

That is also possible. There are quite a few arbitrary limits throughout the code and across many features that, at the time of coding years ago, seemed reasonable but may now be too limiting or small. I will need to look through all of the display-related routines to track this down though.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Okay, I can confirm that this is due to ExtTextOut() returning an error for long strings and is not due to any limits on canvas size or any other display-related feature. It appears to be the same issue mentioned in the discussion on stackoverflow, including this one, indicating a timeout in the ExtTextOut() API when it takes too long to process the string.

The clipping region is set to the size of the window, so ExtTextout() should stop emitting text once it has reached the edge of the clipping region. But it looks like it pre-processes the whole line first, regardless of clipping region width. It may be that it was not optimally designed to handle this much text at once, or perhaps it was designed this way to conserve system resources.

I have implemented a check in the display routines where if the length of the text is 1) longer than the clipping region and 2) longer than 1024 characters, the line length will be progressively halved etc. and the shorter line length is passed to ExtTextOut(). This appears to resolve the issue and will be in the next beta.


Link Copied to Clipboard