Now I could not find the code I have used but here is the latest version
of the game I started developing for the XO-1. (The development stalled
because the xv bug in the Geode driver.)
https://docs.google.com/leaf?id=0B6XMYp250cOmZDhmOWNjMTQtMjNlNy00NDc0LTlhMmItNGI3M2NhMGFmNmVm&hl=en
The trick is that you can develop "xo_bubble_town" on Windows and you
can compile the "xo2d" directory on the XO (copy the pictures there).
I could not find the first version which did not use xv but basically
you have to use XShmCreateImage instead of XvShmCreateImage and use
XShmPutImage instead of XvShmPutImage in "xi2d/XOHardware.cpp".
Now if you are already using those then we cannot help you without you
posting your code I am afraid...
HTH
shivaprasad javali wrote:
We are allocating a 32 bit buffer and then using the X server calls to
blit it to the 16 bit screen. Even this is slowing down the
application as the draw in the application is very intensive. We
commented out parts of our draw code to find out the part which was
slowing it down and found that the blit to the 16 bit screen ( using X
server calls) was responsible for a large chunk of the slowdown. When
we changed the screen depth the performance of the activity increased
dramatically.
I was worried if some other activity on the XO making the opposite
assumption and optimizing their draw code for a 16 bit screen and then
suffering because we changed the default depth.
Thanks
Shivaprasad
2010/1/27 NoiseEHC <noise...@freemail.hu <mailto:noise...@freemail.hu>>
Since you can only blit pictures on an X server and cannot get a
direct pointer to the video memory, I do not know what your
problem is. You can just allocate a 32 bit offscreen buffer in the
address space of your application and blit it via the X server to
the 16 bit video memory (draw). The XO-1 has bit depth converter
hardware so it will not be slower in theory.
Note that you cannot use the video overlay for this because it has
only YUV and RGB-565 modes on the XO-1 and there is a bug in X
that the overlay will be garbage after a suspend and it was not
fixed last time I checked. (I have told that I would fix it but
because I could not figure out how to compile stuff for the XO-1 -
like recompiling the kernel and the X server - I did not fix that.)
If you need it then I could search for the code I have used but it
would take some time...
shivaprasad javali wrote:
Hi All,
We are developing an Activity for the XO. During
development we ran into an issue with the default screen depth on
the XO. Our application assumes that the screen depth is 32 and
does all the draw math. But as the screen depth on the XO is 16
we had to do constant 32 bit- 16 bit conversions which really hit
performance. So we put in script to run after installing our
activity which changes the default screen depth on the XO from 16
to 32 bit.
I wanted to know how much of an issue this would be for
other activities running on the XO. Would they be adversely
affected by this change?
Thanks
Shivaprasad
------------------------------------------------------------------------
_______________________________________________
Devel mailing list
Devel@lists.laptop.org <mailto:Devel@lists.laptop.org>
http://lists.laptop.org/listinfo/devel
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
