I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device
[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr
while remote lcds may compile (and work in the sim) its not been tested on targets
[FIXED] backdrops need work to be screen agnostic
[FIXED] screen statusbar is not being combined into the main viewport correctly yet
[FIXED] screen elements are displayed incorrectly after switch to void*
[FIXED] core didn't restore proper viewport on splash etc.
[NEEDS TESTING] remote lcd garbled data
[FIXED] osd lib garbled screen on bmp_part
[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport
[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer
[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing
[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage
[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags
Change-Id: I0d04c3834e464eca84a5a715743a297a0cefd0af
The build system needed fixes because the tools paths changed and one tool that
we used (apkbuilder) was removed entirely. Recent NDKs don't ship gcc 4.4.3
anymore, therefore switch to 4.6. The code itself needed a fix for a jni
reference bug that was uncovered by KitKat.
The port now builds with latest sdk (r22) and ndk (r9d).
Change-Id: Id74fa54ba93bbb0ee30373fbe79e92c5ff03201d
The scrolling code cannot differentiate between the BUTTON_TOUCHSCREEN post
from normal touches and the one posted in the timeout callback.
To fix introduce a global special button (BUTTON_REDRAW) that results
in the desired redraw. This existed already as a local kludge for android
and is now generalized.
Change-Id: I6bfa6c66431c48f5042fcd8fce2ea72cd3457f58
* rename some java methods (to update(), initialize())
* re-create the ByteBuffer object from the framebuffer on every update.
This is needed now since 2c71aa9 added the possiblity for lcd_framebuffer to change.
* do so, along with the creation of the dirty Rect object, in native code.
Change-Id: Id39ea8e4b6148987c5f216a87e0ff3c8e7babe92
Especially when unzipping rockbox.zip, the native code can be initialized
a lot later than the java code. The java code needs to be prevented from
accessing rockbox structures (e.g. current_tick, event queues) before they're
ready.
This commit adds wait_rockbox_ready() and fixes dodgy behavior of starting
rockbox via widget play button, headset remote buttons or multimedia keys.
Also fixes wrong small list items before first redraw.
Change-Id: I1caf925e829a9c1c6bb6e0016d5c80574574c91e
Change all lcd drivers to using a pointer to the static framebuffer
instead of directly accessing the static array. This will let us
later do fun things like dynamic framebuffer sizes (RaaA) or
ability to use different buffers for different layers (dynamic
skin backdrops!)
Change-Id: I0a4d58a9d7b55e6c932131b929e5d4c9f9414b06
The environment is fine to share in general, just not across OS threads, so it's only needed
for functions which are possibly called from multiple OS threads (only 1 currently).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29601 a1c6a512-1295-4272-9138-f99709370657
The added complexity wasn't needed for most subsystems, as main() never returns
so local references can't be freed.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29570 a1c6a512-1295-4272-9138-f99709370657
* Re-create RockboxFramebuffer instance with every time there's a new Activity.
* Also, allow Rockbox to be started via multimedia buttons, immediately starting playback if wanted.
We don't need to keep the fb instance around when it backround, and it makes us less depending on it and the activity (less race conditions). And this is how you usually do it in Android apps.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29384 a1c6a512-1295-4272-9138-f99709370657
That enables drawing from outside the apps UI thread, i.e. from within the Rockbox native thread, without needing synchronization means, and adds determinism as to when the draw happens.
It simplifies the drawing routines and adds a convinient way of detecting whether drawing should happen or not (surfaceCreated/Destroyed).
It also restores max. fps on my phone which went down drastically with the gingerbread(CM7) update.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29333 a1c6a512-1295-4272-9138-f99709370657
The scrolling engine could lock out the main thread which may be waiting for its update to finish (wakeups are not reentrant).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28821 a1c6a512-1295-4272-9138-f99709370657
test_fps can also now report reasonable numbers: ~62 fps for both 1/1 and 1/4 updates (was 300-400 previously).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28728 a1c6a512-1295-4272-9138-f99709370657
Remove the hardcoded (and way too small) scroll threshold (the distance moved in pixels before we think the users wants to scroll) and replace it with something based on the actual DPI of the screen.
On Android we call the API for that, on other touchscreens we reimplemented Android's formula (as of 2.2) and calculate it.
Flyspray: 11727
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28548 a1c6a512-1295-4272-9138-f99709370657
Remove some @Override annotations to make the Java code build with certain javac versions.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28386 a1c6a512-1295-4272-9138-f99709370657
this greatly reduces CPU load. lcd_update_rect shoves a bit as well.
CPU usage with Rockbox in background is between 3% (with a 200kbps vbr mp3) and 12% (320kbps cbr mp3), so it's low but still dependent on codecs and even particular files.
Driving a WPS with peakmeter, e.g. the builtin one, adds about 30% cpu usage.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27689 a1c6a512-1295-4272-9138-f99709370657
the activity only attaches to the framebuffer for displaying it. An icon
in the notification area is displayed (it could be prettier I guess).
Note: Some HTC phones won't, includng mine, get enough CPU time to do background decoding
fluently, see: http://code.google.com/p/android/issues/detail?id=9663
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27686 a1c6a512-1295-4272-9138-f99709370657
General state is: Rockbox is usable (plays music, saves configuration, touchscreen works too).
Problems:
- Playing music in the background (i.e. when switching to another app) doesn't work reliably, but I'm working on that now.
- no cabbiev2 (only some preliminary files for it), no other default theme.
- screen flickers sometimes if the updates are too frequent
- no multi screen apk/package
- strange behavior when a phone call comes in
The java files (and the eclipse project) resides in android/, which is also supposed to be the build folder.
I've put a small README in there for instructions. There are some steps needed after the make part, which are described there,
and which eclipse mostly handles. But there ought to be some script/makefile rules which do that instead in the future.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27668 a1c6a512-1295-4272-9138-f99709370657
