Impact of changing default Screen depth on other XO Apps

[NoiseEHC]

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 <NoiseEHC at freemail.hu <mailto:NoiseEHC at 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 at lists.laptop.org <mailto:Devel at lists.laptop.org>
>>     http://lists.laptop.org/listinfo/devel
>>       
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100127/a45a0319/attachment.html>