[Spice-devel] androidSpice-0.1.6 released
ykaul at redhat.com
Mon May 16 02:19:50 PDT 2011
On 05/16/2011 12:12 PM, Shuxiang Lim wrote:
> 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));
> encoder->io_next_word = *(encoder->io_now++);
> /World's tranquil again. Forgive me for I've found no easy and cute way...
> Best Rgrds./
Assuming this happens because of non-aligned memory access, perhaps
trying out the suggestion in
> On Sat, May 14, 2011 at 12:51 AM, The Ha <tha at math.ubc.ca
> <mailto:tha at math.ubc.ca>> wrote:
> I just want personally to thank you for this hard work
> Great job
> The Ha
> On Fri, 13 May 2011, Shuxiang Lim wrote:
> 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:
> 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 <http://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
> 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
> 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
> 185 * So I abandon some little rects to low the flow,this is
> 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
> 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.
> Alternate Email <the.ha at ubc.ca <mailto:the.ha at ubc.ca>>
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spice-devel