On 05/16/2011 12:12 PM, Shuxiang Lim wrote:
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./
/
Assuming this happens because of non-aligned memory access, perhaps
trying out the suggestion in
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3721.html
makes sense?
Y.
On Sat, May 14, 2011 at 12:51 AM, The Ha <[email protected]
<mailto:[email protected]>> 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 <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
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 <[email protected] <mailto:[email protected]>>
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
