You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: