[Spice-devel] Release the androidSpice-0.1.3 experimental.

[Shuxiang Lim]

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 <kai.mosebach at bsse.ethz.ch>

> 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 <shohyanglim at gmail.com<mailto:shohyanglim at gmail.com>>
> Date: Mon, 25 Apr 2011 22:49:23 +0800
> To: Kai Mosebach <kai.mosebach at bsse.ethz.ch<mailto:
> kai.mosebach at bsse.ethz.ch>>
> 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 <kai.mosebach at bsse.ethz.ch<mailto:
> kai.mosebach at bsse.ethz.ch>>
> 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" <shohyanglim at gmail.com<mailto:
> shohyanglim at gmail.com>> 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 <shohyanglim at gmail.com<mailto:
> shohyanglim at gmail.com>> 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
> >Spice-devel at lists.freedesktop.org<mailto:
> Spice-devel at lists.freedesktop.org>
>  >http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110425/69c29105/attachment-0001.htm>