[Spice-devel] androidSpice-0.1.6 released

Shuxiang Lim shohyanglim at gmail.com
Mon May 16 02:12:10 PDT 2011


Hi,all!
   I've mentioned before about the common/quic.c will cause SIGBUG on ARM,
then I walked around it by '-O0',it works for armv5,armv7,but I've just
found this didn't work for ARM9,so I have to do the final and fool way to
rewrite some statements in quic.c with memcpy() like this:
*#ifdef ANDROID
     memcpy(&encoder->io_next_word, encoder->io_now++,sizeof(uint32_t));
#else
     encoder->io_next_word = *(encoder->io_now++);
#endif

 *World's tranquil again. Forgive me for I've found no easy and cute way...
Best Rgrds.*
*


On Sat, May 14, 2011 at 12:51 AM, The Ha <tha at math.ubc.ca> wrote:

> I just want personally to thank you for this hard work
> Great job
>
> Thanks
> Cheers
> The Ha
>
>
> On Fri, 13 May 2011, Shuxiang Lim wrote:
>
>  Hi,All!
>>  Since the dilemma I faced in the use of QXL worked around and  the client
>> bugs fixed,I'm glad to
>> release the androidSpice-0.1.6 on google code under LGPL:
>>
>> http://code.google.com/p/spice-client-android/
>>
>> You shall check the wiki page of it for the build/install/use of it or
>> download the .apk or src files.
>> Any use or improvement will be appreciated!
>> Besides, this version will need no change in server side at all,that is,it
>> can process all QXL-mode image types. But its response will be slower than
>> the former server-jpeg way,especially with QXL. The current architect is :
>> 1.libspicec.so acts as the data client and processes all image data from
>> server into image buffer in mem.
>> 2.when image buffer updated,android-worker.c will take the data from
>> buffer,
>> do jpeg_encode,then send the jpg to JAVA UI to display.
>> Here is the reason I commented in jni/android-spice-src/android-worker.c:
>> */*
>> 177  * All the sins comes from the architect of Android: All UI must be
>> 178  * written in Java(at least <2.3), so I have to send the image buffer
>> data to Java
>> 179  * with Little and Fast flow as possible for the Easy display of
>> latter,hence the use of JPEG_COMP.
>> 180  * FIXME:This maybe the only rational way,but that means androidSpice
>> will never leave
>> 181  * the status quo labelled EXPERIMENTAL.Tragic...
>> 182  *
>> 183  * FIXME: androidSpice UI in JAVA can only process the image of
>> horizontal bars
>> 184  * So,even QXL gives me normal tiny rectangles,I should send bars to
>> JAVA.
>> 185  * So I abandon some little rects to low the flow,this is stupid
>> though...
>> 186  */*
>>
>> So I think this is the reasonable way: If not all the type of images be
>> processed, where is the value of SPICE?
>> But the "reasonable" way must face the unreasonable obstacle in
>> Android:How
>> to send image to JAVA UI, with little and fast flow and easy format for
>> java?
>> I choose JPEG,but that's the reason why in QXL will be slower than in VGA
>> STD. And there is no cursor displayed in client in QXL mode for I haven't
>> compose it in JAVA UI.
>>
>> Is my architect right,or is my jpeg_encode decision improvable? Any ideas?
>>
>> (BTW,My contract will expire this month,anyone can advice or introduce a
>> job
>> with handsome salary in China? My current one is bleak..)
>> (另,我合同本月到期,那位能帮在上海介绍一个工资拉风点的工作阿,目前的有点...)
>> (因みに、コントラクトは今月に終わるので、誰がもっと適当なサラリをできる仕事を紹介してくれませんか?上海に居るんですげと。。)
>>
>> Best Regards.
>> --Lim----Lin-----林----
>>
>>
> Alternate Email <the.ha at ubc.ca>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110516/f6d68d8f/attachment.html>


More information about the Spice-devel mailing list