FFI interface for Linux framebuffer (eink-oriented for now) #96
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
we won't likely use it, it is full of bitops, thus pretty slow
this introduces the ability to implement n:m bpp optimized blitting. This allows for a major speedup. Comes with implementation especially for from/to 4bpp blitbuffer blitting.
now that blitbuffer API for A8 format exists, we can use the output of mupdf directly.
RGB16 was dropped since it won't likely be used. Reflect this by removing the according test routine.
4bpp handling was a bit adapted so rotated 4bpp can now be handled easier
tests are now in our test suite
Drawcontext was a bunch of accessor methods to a C struct. We can do this easily with FFI.
This change is backwards compatible - it will still work for the old way of passing Lua userdata objects.
drawcontext.h now only serves to provide the declaration of the drawcontext struct.
Optimized blitting is removed for now. 4bpp buffer handling is greatly
simplified by using Color4{L,U}:set(...) methods.
Inversion and rotation are now done by setting according flags for blitbuffers.
Flag storage is done in the "allocated" uint8_t struct variable of the classic
blitbuffer struct which is still unchanged (and thus compatible to "classic"
C blitbuffers as they were before going to FFI).
It is quite fast even without optimized blitting routines. Nevertheless, the
method to implement optimized routines is still present, so optimized routines
could be created later on. It is probably not wise, though, to focus on 4bpp to
much now that we can work with other formats, too.
For a lot of rendering, we still do 24bpp or 8bpp to 4bpp conversion in C land,
then another 4bpp to 8bpp or 16bpp conversion in Lua/FFI when blitting to the
framebuffer. This could further be reduced to one conversion (if at all).
Now properly does rotation.
both methods didn't take inversion into account. Now their implementation respects inversion.
do not build old einkfb, blitbuffer and drawcontext modules use the FFI implementations in koreader-base wrapper
hwhw
added a commit
to hwhw/koreader
that referenced
this pull request
Nov 26, 2013
This will need koreader/koreader-base#96 to be applied first
|
Unfortunately, this is still untested on Kobo devices - I'll see if I can check on my Kobo Mini. |
|
Looks good. Thanks. |
chrox
added a commit
that referenced
this pull request
Nov 26, 2013
FFI interface for Linux framebuffer (eink-oriented for now)
|
amazing PR :) |
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.
This first simplifies the blitbuffer implementation a bit (again...).
It also implements now properly working framebuffer code (tested only on the KPW 1 for now).
It will need some slight changes in koreader, too, to make full use of the new features.