According to the SD problem:<br>As far as I know emdete has noticed exactly what you assume.<br>Reading from the SD while using the display heavily (in his case this was a VGA Edje/Evas gui) isn&#39;t really possible - the display will work, but the SD won&#39;t get any bandwith, so transfer will be extremely slow or stop completely.<br>
<br><div><span class="gmail_quote">On 4/24/08, <b class="gmail_sendername">The Rasterman Carsten Haitzler</b> &lt;<a href="mailto:raster@openmoko.org">raster@openmoko.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
On Thu, 24 Apr 2008 09:24:26 +0200 polz &lt;<a href="mailto:polz@aufbix.org">polz@aufbix.org</a>&gt; babbled:<br><br><br> &gt; On Thursday 24 April 2008 05:52:52 Carsten Haitzler wrote:<br> &gt; &gt; On Wed, 23 Apr 2008 18:28:40 +0200 thomasg &lt;<a href="mailto:thomas@gstaedtner.net">thomas@gstaedtner.net</a>&gt; babbled:<br>
 &gt; &gt;<br> &gt; &gt; yup. those 7m/sec (that&#39;s write to video ram) is also shared with SD card<br> &gt; &gt; IO.<br> &gt; Correct me if I&#39;m wrong, but it seems to me that this means it should be<br> &gt; impossible to playback videos in full-screen from an SD card on a gta02.<br>
 &gt; 640*480*25 = 7680000 and that&#39;s with 8bpp.<br> &gt;<br> &gt; Has anyone tested video playback on a GTA02 yet ?<br><br><br>correct. yuv will be w * h * 1.5 bytes for 1 frame (standard video yuv). so<br> 3240x240*1.5*30 (320x240 @ 30fps) = 3.4m/sec - BUT... when u are copying you<br>
 have ZERO cpu cycles to decode the next video frame. so that means 50% of cpu<br> cycles will be spent ONLY copying video data to video ram. the other 50% u have<br> left to decode the mpeg1/2/4 or whatever video in system ram to a yuv buffer. i<br>
 would say this is the realistic highest resolution you will get. 480x320@30fps<br> is the MOST you will get (6.9m/sec), but u have ZERO (or almost) cpu cycles to<br> actually decode the video into yuv.<br><br> remember here i am assuming use of xvideo and the yuv to rgb conversion and<br>
 scaling on the glamo - which xglamo does support. if you do software yuv-&gt;rgb +<br> scale then its even less fun. with software. the best u will get is 11fps at<br> 640x480 - and this is NO cpu cycles to actually decode the video, convert it to<br>
 16bit rgb and scale. in reality i expect you to see 2-5fps in this scenario,<br> maybe eve 1fps.<br><br> this is ONLY playback if the video data is already in ram - ie the mpeg data is<br> cached. if it is read off internal flash you will pay an IO cost - but it&#39;s not<br>
 shared with the glamo bus. if it is on SD card - you will basically have to now<br> share the IO between SD and graphics. i believe the graphics IO takes<br> precedence over SD card IO, so as long as u keep the glamo gfx bus busy, sd<br>
 will be on hold until u stop. then some sd io can get through.<br><br> with the glamo you need to be careful what you do and how you do it. if you can<br> keep something entirely within the glamo - it should be ok. so things like<br>
 uploaded pixmaps and then blitting them around is ok. video decode is another<br> matter entirely. the glamo has an mpeg4 decoder on it - but we don&#39;t have any<br> api to access that directly/sanely and just feed it an mpeg4 stream. any other<br>
 codec has to be done on the cpu anyway and uploaded across the bus as yuv data.<br><br><br> --<br> Carsten Haitzler (The Rasterman) &lt;<a href="mailto:raster@openmoko.org">raster@openmoko.org</a>&gt;<br><br><br>_______________________________________________<br>
 Openmoko community mailing list<br> <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br> <a href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</blockquote></div><br>