Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Glyph Boundary Pixel Errors #123

Open
cbratschi opened this issue Aug 23, 2016 · 14 comments
Open

Glyph Boundary Pixel Errors #123

cbratschi opened this issue Aug 23, 2016 · 14 comments

Comments

@cbratschi
Copy link

On macOS X with a retina display I am seeing thin vertical lines at the boundary of glyphs. On a Raspberry Pi the hairlines are also visible if the text is zoomed. Changing from GL_LINEAR to GL_NEAREST did not improve the situation. Is there a simple way to add a thin border between glyphs in the atlas?

screen shot 2016-08-23 at 14 27 41

At the top you can see the atlas texture and the rendered text in blue below.

@rougier
Copy link
Owner

rougier commented Aug 23, 2016

In texture-font.c you can play with the padding:
https://github.com/rougier/freetype-gl/blob/master/texture-font.c#L588

@cbratschi
Copy link
Author

A padding.left of 1 solves the issue. It seems a padding at the left and right is required. I will do some more tests later today.

@cbratschi
Copy link
Author

It works now fine on all devices. Closing this ticket.

@Sakari369
Copy link

Just FYI, I'm seeing this too on Os X.
With the default padding in https://github.com/rougier/freetype-gl/blob/master/texture-font.c#L588:

    struct {
        int left;
        int top;
        int right;
        int bottom;
    } padding = { 0, 0, 1, 1 };

I get this result, where not all of the glyphs have the font overflown, but only some:

default_padding

Now, after hours of debugging and finding this bug report (thx for pointing out to the padding!)
And changing the padding to { 1, 1, 1, 1 }, I get correct result:

modified_padding

Seems that with left padding, some of the font glyphs get positioned too close and the data spills to incorrect glyphs.

Running Mac Os X 10.11.6, non-retina display.
My text initialization code is pretty much identical to the one in the 'demos/lcd.c', only with the exception of not using the LCD rendering in the shader, but which I noticed has no effect.

The demos do not show this artifact for some reason, but I didn't want to go through the troubles of changing the demos from orthographic projection or add zooming controls to maybe see if the artifact is happening when zooming in enough.

Here's a comparison showing the actual quads being renderered:

With the default padding:
default_padding_outline

With modified {1, 1, 1, 1} padding:

modified_padding_outline

@rougier
Copy link
Owner

rougier commented Oct 28, 2016

You suggest we have to modify the padding then ? Can you make a PR (and points to this issue in the comment) ?

@Sakari369
Copy link

@rougier Well. I will still test this with my retina mac also and see if it works, then I can take a look at creating a pull request. Could this be an issue on Os X only, the Truetype library doing something different than in Windows ? No idea.

Stragne thing is I don't see this happening in the provided demos, might be though that the cases are such that this doesn't show up ? I went through the glyph dimensions, positions and shader code to make sure all of those were same in my personal code and in the demos, and still in my own project I could see the offset, although I think the demos were using orthographic projection, that could explain it too, haven't tested orthographic yet on my own project.

@rougier
Copy link
Owner

rougier commented Oct 29, 2016

In any case, it would be better to open a new issue because this one is closed. People will ba able to test on different architectures.

@cbratschi
Copy link
Author

@inDigiNeous I had the same issue on a Raspberry Pi. So this is not related to the retina display. I guess it is related to rounding issues and interpolation. Fractional floats are used for the glyph positions and with interpolation on (which I am using) unwanted pixels might be included while rendering the textures. I would assume it is also related to the size of the atlas. In my case I am using a 512x512 bitmap.

@rougier rougier reopened this Oct 29, 2016
@Sakari369
Copy link

@cbratschi Okay. I noticed that a padding of 1,1,1,1 wont help in all cases, that would still at some edge case show a tiny strip of lines overflowing, when zooming this can become visible. So maybe with 2,2,2,2 padding this might be fixed.

Maybe this should be adjustable by the user when calling ?
I'll have to play around this for some time still to see what works best.

@cbratschi
Copy link
Author

@inDigiNeous how large is your atlas texture? 512x512?

@Sakari369
Copy link

@cbratschi 2048x2048, testing with pretty big fonts so that scaling looks good.

@ofZach
Copy link

ofZach commented May 11, 2022

I just was taking a look at the library and wanted to mention I see the same issues (Mac osx / m1) on some of the demos

Screen Shot 2022-05-11 at 7 07 45 PM

Screen Shot 2022-05-11 at 7 12 45 PM

@rougier
Copy link
Owner

rougier commented May 12, 2022

With default padding? If not, can you try to increase?

@ofZach
Copy link

ofZach commented May 12, 2022

this is cloning from GitHub and compiling as is -- will take a look!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants