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

Better font rendering #4

Open
lawik opened this issue Jul 26, 2019 · 1 comment
Open

Better font rendering #4

lawik opened this issue Jul 26, 2019 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@lawik
Copy link
Collaborator

lawik commented Jul 26, 2019

Problem

The Scenic RPi driver uses nanovg which doesn't allow us to turn off antialiasing. Antialiasing doesn't do us any favors on the Inky.

There is potentially a possibility to create grayscales I've seen discussed too.

This thread: pimoroni/inky#13
has some mention of driving the display faster and it could possibly be used to provide some kind of grayscale if I'm not mistaken. I've seen Inky-library discussion about providing grayscale for the black/white device but not sure if that's doable when driving a color display as a black/white. I don't know nearly enough about the hardware.

Attaching the datasheet referenced (not sure it's the right one) in case that broken SSL-cert is a signifier of the thing going away.
DEPG0420R01V3.0.pdf

Font rendering & native pixels

I've looked at a few options for rendering type in a lightweight way but haven't found an ideal fit. I think it would be somewhat feasible for the driver to draw some primitives on its own or with a library and be a little more low-level. But implementing font rendering from scratch is not something I'm interested in right now.

Removing the dependency on the framebuffer and rendering from primitives to Inky pixels would give the best potential for good results.

Intermediate solution: two-pass dithering?

Another consideration is to see if a two-pass approach to the dithering could make for some better results. Currently it is unaware of surrounding pixels and will just checkerboard anything that falls outside the thresholds for white/black/accent.

If it did a second pass it could ascertain that it has a big enough block of color in the neighborhood around it to make a good effect before deciding what to draw.

@lawik lawik added enhancement New feature or request help wanted Extra attention is needed labels Jul 26, 2019
@lawik
Copy link
Collaborator Author

lawik commented Jul 26, 2019

Also, this should possibly look better with some pixel-perfect fonts: memononen/nanovg#478

Want to verify that, I know nerves-training tried to do that. But not sure if they got it working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant