macOS: lines on gutter, painting glitch

[veksha]

Hello, @Alexey-T. I know how to fix https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39841 , but first I need be able to tell where is CudaText's bug and where is Lazarus'. So let's start by fixing these gutter lines: some of them are antialiased??

[Alexey-T]

interesting! here is function which paints all this stuff:

procedure TATSynEdit.DoPaintGutterFolding file atsynedit.pas

In its beginning, try to add:

begin
  if not FOptGutterShowFoldAlways then
    if not FCursorOnGutter then exit;

  C.AntialiasingMode:= amOff; // or maybe amOn helps??

[Alexey-T]

i tried to find 'AntialiasingMode' in all compponents (atsynedit, atflatcontrols) and didnt find any. so maybe we have another reason.

[veksha]

oh.. Lazarus has similar problems.

[veksha]

@JairoMartinezA Hi, This is your screenshot from another issue. I have a question. Is this macOS? do you see issues with folding lines on the gutter? (the same as on my screenshots.)

[JairoMartinezA]

I don't think so, and yes, this is from MacOS:

[veksha]

I don't think so, and yes, this is from MacOS:

let me ask another questions, what is your display (retina?) what is your resolution? and do you see issues (similar to mine) in Lazarus by chance?

[veksha]

this is another screenshot of yours. I see small bug with horizontal line being 1-pixel more then needed, but nothing too serious. hm...

[JairoMartinezA]

Yes, I really don't use Lazarus, I only have to compile CudaText with las changes of Alex:

This is the way as Lazarus shows the editor currently with last FPC:

In CudaText currently I don't have seen weird cases. The only thing with previous FPC (maybe) was when I was compiling from Lazarus, the y-space was higher (visually) even if I didn't touch these values:

but with updated FPC and with updated CudaText code, now is normal.

[veksha]

I don't think so, and yes, this is from MacOS:

let me ask another questions, what is your display (retina?) what is your resolution? and do you see issues (similar to mine) in Lazarus by chance?

@JairoMartinezA do you have 4k resolution (retina display)? (and maybe scaled macOS UI?)

maybe nowadays no one is using macOS-es with 1920x1080 resolution?

if you set caret_view to 2,-100 or 3,-100 do you see difference between them?

thank you for answers!

[JairoMartinezA]

This is my current configuration:

[JairoMartinezA]

Ready @veksha

https://user-images.githubusercontent.com/5806694/185430693-512303e7-b83e-4eb8-8895-abd08d1c1057.mov

[Alexey-T]

My suggestion in 2nd post didn’t help?

[veksha]

My suggestion in 2nd post didn’t help?

helped to remove faint line for me! but all glitches with gutter is happening only for me on my full hd display (not retina) i don't know if we need to fix them, because macOS users on their displays may not see them. (if they all have retinas?) but i see problem with caret width anyways on @JairoMartinezA machine, so strange. so maybe we need to fix this pixel allignment for full-hd displays to fix all problems.

i know how to fix it in cocoagdiobjects.pas in LineTo procedure:

using recommendation from here:

"On a low-resolution display (with a scale factor of 1.0), a one-point-wide line is one pixel wide. To avoid antialiasing when you draw a one-point-wide horizontal or vertical line, if the line is an odd number of pixels in width, you must offset the position by 0.5 points to either side of a whole-numbered position. If the line is an even number of points in width, to avoid a fuzzy line, you must not do so."

https://developer.apple.com/library/archive/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/GraphicsDrawingOverview/GraphicsDrawingOverview.html

(with disabled anti-aliasing faint/fuzzy line will become fully black! that is why pen width is weird)

[Alexey-T]

so what that 'my fix' (setting antialiasing) did change on your screenshot?

[veksha]

it removed faint line, so all lines is now exactly 1px wide. but they will still be in wrong position, because we need to apply fix from my prev post. (i.e. "if the line is an odd number of pixels in width, you must offset the position by 0.5 points")

after turning off aa:

after turning of aa + offset fix:

[Alexey-T]

so now I applied AA fix in atsynedit repo. about 2nd half of the fix - you can post it to related Laz issue, right? or new issue there

[veksha]

so now I applied AA fix in atsynedit repo

good. thanks.

about 2nd half of the fix - you can post it to related Laz issue, right? or new issue there

yes. another interesting reading with pictures here: https://stackoverflow.com/questions/10008286/core-graphics-is-not-drawing-a-line-at-the-correct-width

I just need to test caret width and it will be ready.

[Alexey-T]

great work! thank you...

[Alexey-T]

veksha, my wish for the patch: include few comments, because next ppl will not understand why code moves 0.5 pixels here and there... give docs URL

[Alexey-T]

veksha, no update on this? no lazarus patch planned?

[veksha]

planned but "on hold". most macOS users wouldn't even notice this bug, because this happens only in non-HiDPI mode.

[veksha]

if you know who can fix this, I can provide details for him.

[Alexey-T]

Dmitry @skalogryz is main supporter of Cocoa code.

[veksha]

@JairoMartinezA Hi. caret width is OK for you? maybe noticed some line painting glitches? I guess everyone is on HiDPI and all is ok for them.

[JairoMartinezA]

I tried changing my screen resolution, but even with this change the lines shows OK.

[Alexey-T]

no problem for ppl now? so let's close, @veksha ?

[veksha]

yes. macos users will not notice this kind of bugs. they all have high dpi monitors.