Rockbox mail archive
Subject: Fwd: kugel: r28386 - in trunk: android/src/org/rockbox firmware/target/hosted/android
Fwd: kugel: r28386 - in trunk: android/src/org/rockbox firmware/target/hosted/android
======== QUOTE ==========
Date: 2010-10-30 01:12:08 +0200 (Sat, 30 Oct 2010)
New Revision: 28386
Initialize (instantiate) RockboxFramebuffer from the C code like with
the othe java objects.
Remove some @Override annotations to make the Java code build with
certain javac versions.
======== END QUOTE ==========
Why was this done? I think it was alot cleaner with the java
initialising this class. JNI isnt really nice and we should try
limiting the amount of calls from C->java, especially classes like the
framebuffer which are logically linked to the java side more than c
(which should only need to have access to that classes lcd_update()
and lcd_update_rect(), all other functions go java -> c ).
Furthermore, the way fb is being used is I think rather nasty. We are
checking its resistance to see if rockbox is actually running instead
of Doing It Properly.
Doing it this way also possibly limits our options with handling the
different screen sizes (and multiple screens - i.e widgets - ) in a
single build. Java should be telling C "use 480x800" not the other way
around. (Obviously once LCD_WIDTH/HEIGHT are changed to runtime
Another reason this is bad is how do we clean up resources to do a
clean restart of the service? before this we could have (in theory)
just killed the thread and not wasted any java objects, now we rely on
the vm to clean up alot more (I don't know if that is actually a
reasonable expectation here or not).
Received on 2010-10-30
Page was last modified "Jan 10 2012" The Rockbox Crew