-
Notifications
You must be signed in to change notification settings - Fork 105
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
Add a few RGB-aware set & blend methods to the blitters #1680
Conversation
Initial inspiration. koreader/koreader#9024 (comment) |
Unrelated, but all of a sudden after pushing to forks I am unable to recompile. Any pointers would be helpful since I haven't touched 3rd-party deps.
|
Make sure your submodules are up-to-date and point to the right place (both base's and base itself), then try a |
Fixed the above. A fresh clone also had issues so I figured out it was something with the machine and not the koreader repo.
It looks like installing a system package added those variables by default.
Unsetting the above fixed everything and now I can compile again. I'll work on resolving your comments. |
New revision should have support for other screentypes and for real color blending (stacking multiple highlights makes the color get stronger and stronger). |
Newest revision supports color pdf highlights. If new |
c610c9a
to
df9fb03
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed some minor simplifications, but have NOT tested them, I've just checked that it built (and was generating similar machine code before actual logic deviations were implemented ;p).
Reviewed 1 of 3 files at r2, 3 of 3 files at r3, 1 of 1 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @smasher816)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r5, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @smasher816)
Is this ok? (I mean: ready to merge?) |
Needs testing ;). |
@poire-z: Because I'm super lazy, If you have a random test file with colored text on hand, that could come in handy. Thanks ;). |
I know :) |
And re-implement RGB32 fast path
(Jokes aside, we tend to prefer that syntatcit sugar (and string methods) as opposed to calling string.fn(obj) explicitly).
Requires a few bendRGB32 shims for Color <= 8A, as the usual blend methods assume Color8 input.
Which is the one we actually care about, as we don't actually have any colorblitFromRGB32 callers ;).
To deal with highlights on sw nightmode...
Implement a grayscale and a color one, like other setters Instead of implementing a full array of per-color type blend methods
And round the component values to 16 shades per component.
We often need a copy anyway, so take the opportunity to make this safer ;)
This allows us to fairly easily make gray behave as our legacy grayscale highlights, honoring the user's opacity value.
Matches what I did for BB_color_blit_from_RGB32
These are unsigned, they can't be negative ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 4 of 4 files at r8, 1 of 1 files at r9, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @smasher816)
Apparently, 8 wasn't enough, the highlight style dialog was still cutoff :/
dithering. So, rejig that so we can tweak that on a per-device basis, too.
Hey, look, I've finally gotten around to finish this before the PR's first birthday ;p. (I basically just want to test a few color changes tomorrow, but other than that, it's ready). |
ChangeLog:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r10, 1 of 1 files at r11, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @smasher816)
Commit history will be archived in my color-highlights branch |
koreader/koreader-base#1894 koreader/koreader-base#1908 koreader/koreader-base#1909 koreader/koreader-base#1904 koreader/koreader-base#1910 koreader/koreader-base#1911 koreader/koreader-base#1912 koreader/koreader-base#1901 koreader/koreader-base#1913 koreader/koreader-base#1680 koreader/koreader-base#1915 koreader/koreader-base#1916 koreader/koreader-base#1914
koreader/koreader-base#1894 koreader/koreader-base#1908 koreader/koreader-base#1909 koreader/koreader-base#1904 koreader/koreader-base#1910 koreader/koreader-base#1911 koreader/koreader-base#1912 koreader/koreader-base#1901 koreader/koreader-base#1913 koreader/koreader-base#1680 koreader/koreader-base#1915 koreader/koreader-base#1916 koreader/koreader-base#1914
Add new BB_fill_rect_color and BB_blend_rect_color functions taking a ColorRGB32.
Use a new is_rgb flag in Color structs for lua wrapper to decide which BB_ function to call.
If a ColorRGB32 is passed to fillRect/lightenRect then the new path will be taken. Otherwise original Color8A/uint8_t code is called.
No changes should occur for existing code paths. Callers must be patched to provide RGB colors if desired.
Lua blitbuffer implementation has not been changed.
This change is