#525 TCoolEdit: Rendered characters are partly chopped

[Vidar Hasfjord]

When using syntax highlighting, the text rendering in TCoolEdit has an issue, whereby a character will be partially chopped (overwritten) on its right side, if a space or punctuation mark follows.

Note that this is not an issue, and text is rendered fine, when there is no syntax highlighting. Also, text within comments and string literals render fine, even when syntax highlighting is active. So the issue seems to only occur between adjacent and different syntactical elements, e.g. keyword or identifier followed by whitespace or punctuation.

See attached screenshot.

[Vidar Hasfjord]

This issue has now been fixed [r8391]. Resolution: The background and text are now drawn in two passes. First, the backgrounds for the tokens are drawn, then the texts for the tokens are drawn on top in transparent mode. This eliminates the chopping caused by the background of a token overwriting the text of the previous token where there is slight overspill.

[Erwin Lotter]

Hi Vidar,

while merging your fix to branch-7-coolprj-dev I was wondering why the issue occured at all, because the text output actually seems quite simple and clear. It seemed to me as if ExtTextOut draws to the left of the specified origin. So I simply tried to clip the output rect appropriately and it actually helps ExtTextOut to do things right.

[Vidar Hasfjord]

@elotter wrote:

It seemed to me as if ExtTextOut draws to the left of the specified origin. So I simply tried to clip the output rect appropriately and it actually helps ExtTextOut to do things right.

That's very interesting. Thanks for reporting back!

I thought it was the character itself (e.g. "W") slightly overspilling into the next cell (due to font smoothing), meaning that clipping wouldn't solve the problem. That you have discovered that it is actually the background overspilling is crucial to truly understanding the problem.

On the trunk, as described earlier, the issue is circumvented by rendering the text in two passes; background and foreground. This allows us to not use clipping, which I presume is slower (*). On the other hand, having to render the text in two passes has a performance impact, of course. I'm not sure which solution wins in the end.

* The documentation of the DT_NOCLIP flag for DrawText states that it is "somewhat" faster. However, there is no comment about performance impact in the documentation of the ETO_CLIPPED flag for ExtTextOut.

Edit: My benchmarking shows that Erwin's solution is a clear win. It is also simpler code. For these reasons, [r8391] has been replaced by this better solution [r8451].