Hi,Kai, Yep,all the sin of Android is its framework: Java UI layer. But since there are the ARM optimization for dalvik VM, as well as the opengl ES/alsalib APIs for Java in Android, it's worthy trying to achieve a completely Java porting ONLY IF your have enough time/energy/bugget of this... Rgrds.
2011/4/25 Mosebach Kai <[email protected]> > Too bad, that’s exactly what I was thinking of though (totally native, > leaving out JNI hybrid) => for use in an applet for instance… > > But thanks for the insight! > > From: Shuxiang Lim <[email protected]<mailto:[email protected]>> > Date: Mon, 25 Apr 2011 22:49:23 +0800 > To: Kai Mosebach <[email protected]<mailto: > [email protected]>> > Subject: Re: [Spice-devel] Release the androidSpice-0.1.3 experimental. > > Hi,Kai, > Sorry but I've not got your meaning, you mean,"How to rewrite all of > spice-client in Java"?(rather than my current "Hybrid" work?) > If yes, it's possible and not very hard for the proficient Java guys to > implement the spice protocol in Java and leave the image/audio computing > works( such as the work of pixman,celt,etc..) remained for C in lib*.so for > JNI use by Java. It should not be FULLY rewritten 'cause I don't trust the > maths computing ability of Java. > Regards. > > 2011/4/25 Mosebach Kai <[email protected]<mailto: > [email protected]>> > Hi Shuxian, > > How probable / easy would it be to generate a (native) Java port out of > this assuming that we leave Sound Support out for now? > And (beside me owning an Galaxy Tab w/ Android <2.3) wouldn't it be much > easier (and maybe better) to just leave out Android <2.3? > > Cheers and Thanks for the great Work! > > Kai > > On 4/25/11 3:08 PM, "Shuxiang Lim" <[email protected]<mailto: > [email protected]>> wrote: > > >After some tracing work: I found that,when no input occurs in the > >client,the output flow from server to client may be jammed by the slow > >network but will never be choked.But when there's input, the client > >will always fall soon in the endless calling for coroutine_yield() and > >coroutine_swap() in coroutine_gthread.c (for threads prior > >swapping???why should this?) and usually cause the "yield to > >itself"-->abort() -->segfault. Thus,client will have no mood to > >receive data from server at all,and the output will be choked(input > >still OK). > > So,why does such dead-lock-liked thing happens only on android,how > >can I fix this,or how can I disable such Swapping? Any ideas? > >Rgrds. > > > > > >On 4/25/11, Shuxiang Lim <[email protected]<mailto: > [email protected]>> wrote: > >> Hi,all! > >> I'm happy to release the experimental androidSpice under > >>LGPL,welcome to > >> improve! > >> The source and wiki now dwell in google code site here: > >> http://code.google.com/p/spice-client-android/ > >> All introductions of porting can be found or redirected in the wiki > >> page. > >> > >> The structure of androidSpice: > >> 1.Data layer,extracted from spice-gtk-0.5, the main logic and data > >> transportation/proccessing of spice protocol,along with all its > >> dependencies,built statically into libspicec.so > >> 2.Data layer will add two new threads in android-worker.c for the I/O > >>with > >> Java UI layer via UNIX-sockets(see the PROBLEMS below) > >> 3.UI layer,rewritten in Java. Output the Images and capture user-input > >> events and communicate with libspicec.so. > >> > >> PROBLEMS: > >> > >> "The damned greatest obstacle I've faced in the porting lies in the > >> structure of Android itself:It has no(at least for version<2.3 ) exposed > >> audio/image output and input API for C(only Java!)! So I have to > >>transport > >> all the fixed data got from spice-server to Java layer by adding two new > >> threads to handle the I/O communication with Java UI via two > >> UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client > >>is > >> buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no > >> better way but to force use of JPEG compression in server and the client > >> will send jpeg data directly to Java UI for output, it's queer and > >>should > >> be > >> condemned('cause Spice's value is in the image processing ability)" > >> > >> So now It just WORKS,but works badly, the first untolerable bug is this > >> > >> Bug 1:If press fast on the device the spice-server as well as the > >> android-spice-client will be choked and no image updates will be sent > >>out > >> from server. > >> I'm still working on this bug,I need help! > >> > >> Best regards, > >> --林 > >> > >_______________________________________________ > >Spice-devel mailing list > >[email protected]<mailto: > [email protected]> > >http://lists.freedesktop.org/mailman/listinfo/spice-devel > > >
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
