Kobo viewport #14
Merged
Kobo viewport #14
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
Next comes the logic to unfuck everything...
everything by piggybacking on the viewport code... Bonus: this puts us farther away from the top & bottom edges.
For some mysteriously obscure reason, inlining this tanks performance in the image codepath. o_O.
stupid mistakes :D.
We piggyback on that feature for vertical offsets when the fit isn't perfect.
|
All this piggybacks on the h/voffset feature, which I'm hoping I've tested sufficiently to squish all the corner-cases... Which means that if anything feels or looks wonky after this merge, I'm interested ;). |
Missed one region origin Forgot to make viewVertOffset actually honor no_viewport ;).
horizontal offset
rounding instead of truncating was more better good. :D.
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.
Handles the utter insanity that is devices with rows of pixels hidden by a bezel by fucking design.
That's the H2O, for sure (top 11 pixels, according to Nickel. Depending on the shitty fit of the IR array on your specific device, you might actually be able to see a few of those, if you're being ornery and looking at it at an extreme angle).
The Aura, quite likely, although I've never managed to get a proper screenshot to confirm the exact amount of pixels (most likely around 10 at the bottom). It makes even less sense than on the H2O, because unlike the H2O, I think the Aura's using a capacitive grid?!
Madness.
And the H2O² is a question mark... I'd have hoped they wouldn't have kept this bit of design insanity, but the fact is, we're using the same viewport as the H2O on those in KOReader, and someone has yet to complain about those 11 blank pixels on top, so... -_-".
In any case, right now, that's only enabled on the H2O, because in this instance, I'll only believe what I can see with my own eyes ;).
In a somewhat related fashion, piggyback on that to ensure that rows are "centered" on the usable screen height when we can't perfectly fit the final line on screen (which happens to now be pretty much always on the H2O, because 1429 is way less friendly to multiples of 8 than 1440 ;D).
This should ensure that row 0 is always usable (& visible), but it also means that stuff will very likely shift vertically by a few pixels, compared to the current behavior, where row 0, col 0 is always at (0, 0).
(It's a simple translation, it will not generate background padding like, well, padding does ;)).
That's enabled everywhere it's needed, but it will NEVER affect images. Only the "hardware" viewport is honored in the image codepath.
All this can optionally be toggled off, to restore the current behavior.