Page 1 of 2

very slow PHAL flip times on ASUS 696 wm6

PostPosted: Nov 20, 2007 @ 12:30pm
by GyLgames
I have ASUS A696 (XScale 416Mhz), and my backsurface flip (display->Update()) time is about 30-31ms and its very-very slow. On other older/slower device this time only max. 5-15ms.

Maybe the wm6 slows down the graphic driver (?), because I compared some A696 SPB benchmarks and on wm5 the results were 10-15 times faster the graphic tests. (I didnt find wm6 results - only mine)

PostPosted: Nov 20, 2007 @ 5:44pm
by Kzinti

PostPosted: Nov 21, 2007 @ 12:25am
by GyLgames

PostPosted: Nov 21, 2007 @ 1:47am
by Kzinti

PostPosted: Nov 21, 2007 @ 9:53am
by GyLgames
I tried the logging version... seems everything ok
please, check the attachment,

Thanks

PostPosted: Nov 21, 2007 @ 10:29am
by GyLgames
The minimal.exe (flips green and red bg) has only 30fps.

I noticed in SPB benchmark at "DDB bitblt test" (flips two pictures X times) in portrait mode took 31ms in landscape mode took only 2ms (very fast flips)... I dont know what this means, but maybe help you.

Thanks

PostPosted: Nov 21, 2007 @ 6:02pm
by Kzinti
This is interesting. The GETRAWFRAMEBUFFER values are all over the place:

Width = 181684
Height = 240
xPitch = 269079816
yPitch = 146648
Framebuffer = 46600480

Only the height and framebuffer address look valid. Because of this, PocketHAL skips the driver and uses GAPI instead (that is buffered!)

I will do more research / thinking.

PostPosted: Nov 21, 2007 @ 6:20pm
by Kzinti
Sounds like GETRAWFRAMEBUFFER is deprecated / unsupported in WM6.

I have some idea how to work around that, I'll get back to you asap.

The fact that it uses GAPI on WM6 explains why it is much slower in landscape mode.

PostPosted: Nov 21, 2007 @ 6:47pm
by GyLgames
Thank you for dealing with my problem...

PostPosted: Nov 30, 2007 @ 11:26pm
by GyLgames
any progress? or dead thread...

PostPosted: Dec 1, 2007 @ 12:30am
by Kzinti
I am a bit busy at this time. But I am still working on it.

PostPosted: Dec 1, 2007 @ 1:38am
by GyLgames
oh, thx, good to hear

PostPosted: Dec 6, 2007 @ 6:46pm
by Kzinti
I will need to implement a DirectDraw driver to solve the issue. I should be able to do that over the weekend.

PostPosted: Dec 11, 2007 @ 8:22am
by Kzinti
I've already spend many hours on this and I am having a hard time getting DirectDraw to behave properly.

Changing the shell orientation causes the primary surface to be lost (expected), but I seem unable to recover from it. ISurface::Restore() succeeds, locking the surface succeeds, but then the display doesn't update anymore and my device is frozen.

Just lettting you know I am still working on it.

PostPosted: Dec 11, 2007 @ 11:54am
by GyLgames
thank you very-very much, I sent little donate :D

"The Ultimate Answer to Life, The Universe, and Everything"

I sux nowadays with the datatype misalignmet in vs2005 (ok I know the __unaligned keyword and struct alignment setting, but these dont solve always vs2005-ARM compiler bug)...