-
Notifications
You must be signed in to change notification settings - Fork 24
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
Alpha-blending of AA in OT #22
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's a few percent faster, bt not much ;).
To at least point to something useful everywhere, at least on Kindle/Kobo. Hard-coding a custom font with a Kobo-specific path wasn't the greatest idea ;).
Can't exactly replicate the "invisible ink" behavior of the non-AA rendering, but, eh.
I kind of broke stuff on 167 dpi screen with the dpi switch. We in fact pretty much never want to use native cell sizes anywhere ;).
Can we please burn those with fire?
I refrained from going crazy on the per-bpp branches like in the image codepath, because that was painful enough ;p. |
As @shermp pointed out (#20 (comment)) Thanks!
... which actually avoided a bug, because this is wrong ;p.
We're using the pen*Color globals, which already do ;).
Should be slightly nicer that a segfault, though... Because loading a system font is *probably* something someone would try to do...
In this context, it should just exchange fg <-> bg Granted, now that we can set pen colors, making everything actually do a real invert might make more sense...
Premultiply when it's a fixed color, and use MUL255 otherwise. Has a fairly neglibible impact, unlike DIV255 ;).
It now always actually inverts the color, instead of sometimes swapping fb with bg Because the latter no longer makes any sense now that we can actually set those and they're no longer hardcoded to B&W...
We want to avoid dimensions larger than the screen, not the viewport ;). Fix the 11px of the H2O viewport being chopped off a fullscreen_region, leading to 11px not being updated at the bottom of the screen.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using stbtt's alpha coverage mask when we have to...
c.f. the last few comments in #20
I'll let it sit for a while, because fire bad, tree pretty right now. >_<".
But it appeared to behave okay on 32bpp, 8bpp, and 4bpp (AAAAAAAAAARRRRRRRRRGGGGHHHH).