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. <div class="gmail_quote">On Sat, May 14, 2011 at 12:51 AM, The Ha <<a href="mailto:tha@math.ubc.ca">tha@math.ubc.ca</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I just want personally to thank you for this hard work Great job Thanks Cheers The Ha<div><div></div><div class="h5"> On Fri, 13 May 2011, Shuxiang Lim wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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: <a href="http://code.google.com/p/spice-client-android/" target="_blank">http://code.google.com/p/spice-client-android/</a> 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 : <a href="http://1.libspicec.so" target="_blank">1.libspicec.so</a> 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-----林---- </blockquote> </div></div> Alternate Email <<a href="mailto:the.ha@ubc.ca" target="_blank">the.ha@ubc.ca</a>></blockquote></div>