<div>Hi,Kai,</div>
<div> 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...</div>
<div> Rgrds. <br><br></div>
<div class="gmail_quote">2011/4/25 Mosebach Kai <span dir="ltr"><<a href="mailto:kai.mosebach@bsse.ethz.ch">kai.mosebach@bsse.ethz.ch</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Too bad, that’s exactly what I was thinking of though (totally native, leaving out JNI hybrid) => for use in an applet for instance…<br>
<br>But thanks for the insight!<br><br>From: Shuxiang Lim <<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a><mailto:<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a>>><br>Date: Mon, 25 Apr 2011 22:49:23 +0800<br>
To: Kai Mosebach <<a href="mailto:kai.mosebach@bsse.ethz.ch">kai.mosebach@bsse.ethz.ch</a><mailto:<a href="mailto:kai.mosebach@bsse.ethz.ch">kai.mosebach@bsse.ethz.ch</a>>><br>Subject: Re: [Spice-devel] Release the androidSpice-0.1.3 experimental.<br>
<div class="im"><br>Hi,Kai,<br> 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?)<br> 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.<br>
Regards.<br><br></div>2011/4/25 Mosebach Kai <<a href="mailto:kai.mosebach@bsse.ethz.ch">kai.mosebach@bsse.ethz.ch</a><mailto:<a href="mailto:kai.mosebach@bsse.ethz.ch">kai.mosebach@bsse.ethz.ch</a>>><br>
<div class="im">Hi Shuxian,<br><br>How probable / easy would it be to generate a (native) Java port out of<br>this assuming that we leave Sound Support out for now?<br>And (beside me owning an Galaxy Tab w/ Android <2.3) wouldn't it be much<br>
easier (and maybe better) to just leave out Android <2.3?<br><br>Cheers and Thanks for the great Work!<br><br>Kai<br><br></div>
<div class="im">On 4/25/11 3:08 PM, "Shuxiang Lim" <<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a><mailto:<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a>>> wrote:<br>
<br>>After some tracing work: I found that,when no input occurs in the<br>>client,the output flow from server to client may be jammed by the slow<br>>network but will never be choked.But when there's input, the client<br>
>will always fall soon in the endless calling for coroutine_yield() and<br>>coroutine_swap() in coroutine_gthread.c (for threads prior<br>>swapping???why should this?) and usually cause the "yield to<br>>itself"-->abort() -->segfault. Thus,client will have no mood to<br>
>receive data from server at all,and the output will be choked(input<br>>still OK).<br>> So,why does such dead-lock-liked thing happens only on android,how<br>>can I fix this,or how can I disable such Swapping? Any ideas?<br>
>Rgrds.<br>><br>><br></div>
<div>
<div></div>
<div class="h5">>On 4/25/11, Shuxiang Lim <<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a><mailto:<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.com</a>>> wrote:<br>>> Hi,all!<br>
>> I'm happy to release the experimental androidSpice under<br>>>LGPL,welcome to<br>>> improve!<br>>> The source and wiki now dwell in google code site here:<br>>> <a href="http://code.google.com/p/spice-client-android/" target="_blank">http://code.google.com/p/spice-client-android/</a><br>
>> All introductions of porting can be found or redirected in the wiki<br>>> page.<br>>><br>>> The structure of androidSpice:<br>>> 1.Data layer,extracted from spice-gtk-0.5, the main logic and data<br>
>> transportation/proccessing of spice protocol,along with all its<br>>> dependencies,built statically into libspicec.so<br>>> 2.Data layer will add two new threads in android-worker.c for the I/O<br>>>with<br>
>> Java UI layer via UNIX-sockets(see the PROBLEMS below)<br>>> 3.UI layer,rewritten in Java. Output the Images and capture user-input<br>>> events and communicate with libspicec.so.<br>>><br>>> PROBLEMS:<br>
>><br>>> "The damned greatest obstacle I've faced in the porting lies in the<br>>> structure of Android itself:It has no(at least for version<2.3 ) exposed<br>>> audio/image output and input API for C(only Java!)! So I have to<br>
>>transport<br>>> all the fixed data got from spice-server to Java layer by adding two new<br>>> threads to handle the I/O communication with Java UI via two<br>>> UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client<br>
>>is<br>>> buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no<br>>> better way but to force use of JPEG compression in server and the client<br>>> will send jpeg data directly to Java UI for output, it's queer and<br>
>>should<br>>> be<br>>> condemned('cause Spice's value is in the image processing ability)"<br>>><br>>> So now It just WORKS,but works badly, the first untolerable bug is this<br>
>><br>>> Bug 1:If press fast on the device the spice-server as well as the<br>>> android-spice-client will be choked and no image updates will be sent<br>>>out<br>>> from server.<br>>> I'm still working on this bug,I need help!<br>
>><br>>> Best regards,<br>>> --林<br>>><br>>_______________________________________________<br>>Spice-devel mailing list<br></div></div>><a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a><mailto:<a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a>><br>
<div>
<div></div>
<div class="h5">><a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a><br><br><br></div></div></blockquote></div><br>