No direct video buffer access on WM2003 Second Edition

[Guest SpaceRain]

Have you tried PocketHAL on 2003 SE? I know you can't use it because of GPL, but it could settle this argument.

[Guest The PocketTV Team]

Have you tried PocketHAL on 2003 SE? I know you can't use it because of GPL, but it could settle this argument.

I'm sure the author will try it when the devices come out (at which point it will be too late to fix anything, naturally).

But I know already that it will not work in some cases, because of this:

http://www.pocketpcthoughts.com/forums/vie...p=233239#233239

There is no magic: if someone removes your buffer while you write in it, you'll crash. No need to try it, you can just derive that it will not work, by using pure logic.

Of course this problem only affects Pocket PC at this time, because on-the-fly rotation is not yet supported by Smartphones.

I'm not gonna argue anymore. You have all the information. You should know what to do. Good luck to all.

[Guest spacemonkey]

PocketHal doesn't have those license problems anyway. It's NOT GPL.

It's copyrighted software. You are allowed to distribute it's library with your application, you are not allowed to distribute it's library seperately or as part of your own library.

The only restriction is that PocketHAL has a splash screen and you must donate money to the author to get a splash free version.

As to whether it's higher or lower level than GAPI.

PocketHAL WILL GIVE YOU THE SAME AS GAPI.

You can use it's double buffering solution if you want, but when you create the display you can choose from these options:

enum SwapEffect

{

SWAP_NONE, // Direct access (no buffering)

SWAP_DISCARD, // We don't care about the content of the backbuffer

SWAP_COPY, // We want to keep the backbuffer content

};

So, SWAP_NONE would appear to be I don't want double buffering just let me at that memory.

SWAP_DISCARD and SWAP_COPY would be I want double buffering and orientation.

So it's GAPI, but giving you a few more features if you want to use them.

[Guest SpaceRain]

I'm sure the author will try it when the devices come out (at which point it will be too late to fix anything, naturally).

Ah, I thought you had access to a 2003 SE device.

[Guest The PocketTV Team]

Ah, I thought you had access to a 2003 SE device.

We have access to several 2003 SE devices.

But we don't have time to try all games libraries, especially the ones we don't use in our own developments. If this was your question...

[Guest SpaceRain]

That was my question, thank you.

[Guest SpaceRain]

Ok, here's a bit more info on what PocketHAL actually is. This is taken from their forum and it's all quotes from Thierry, the maker of PocketHAL:

"In most cases, PocketHAL has a more efficient way of accessing the display hardware then GAPI."

"Saying that GAPI access directly the hardware isn't wrong. That's exactly what GAPI does. Unfortunately, it doesn't do so in the most efficient way, and this is where PocketHAL comes into play."

"Multiple technics are being used to update the display, depending mostly on the chipset used to control the video.

Unfortunately, I am not able to discuss them as I would have to reveal information I am not able to. I am under various Non Disclosure Agreements (NDAs), both with companies and individuals."

"I do not use any backdoors into the hardware. ... In the best case, some optimizations will be used. Worst case, you will get the same performances as GAPI. Optimizations are all related to the processors and video controllers, not secret backdoors into the OS."

I think this means I'm wrong about what PocketHAL is and Arisme and Midnight are right. PocketHAL CAN give faster graphics than GAPI without ever calling GXBeginDraw(). This guy knows what he's doing, even if I still don't understand where he gets his GAPI rotation benchmarks from.

"Until I get my hands on a WMP2003 SE device, there is no way to know [whether PocketHAL will work] for sure. In any case PocketHAL will be extended to use this new escape call when available."

If he, with his knowledge of the hardware, can't say now whether it will work or not, then WE sure can't. Guess we'll just have to wait and see. Either way everything should be ok if the developers implement the solution "The PocketTV Team" is requesting.

[Guest The PocketTV Team]

Again, GAPI does nothing. It does not write in the video frame buffer.

In PocketTV, we use GAPI to know where the frame buffer is located, but we use techniques similar to PocketHAL to access the frame buffer in different ways depending on the type of hardware.

So PocketTV does just like PocketHAL. GAPI, again, does *nothing* but tell you the virtual address where the raw frame buffer is mapped. Big deal.

So comparing the speed of PocketHAL and GAPI does not make any sense at all. Since GAPI does nothing at all, it is blazingly fast :D And it is faster than anything.

But comparing using memcpy vs PocketHAL to copy some bytes in the raw frame buffer, this makes sense, and naturally PocketHAL will be faster.

> Either way everything should be ok if the developers implement the solution "The PocketTV Team" is requesting.

Unfortunately the problem is not with the developers (they can use what they want to write into the raw frame buffer, they can you PocketHAL or their own routines). The problem os with the OEM: Will they give developer access to the raw frame buffer.

Also, the problem is more serious with Pocket PC, because of the on-the-fly rotation that can change the raw frame buffer.

It's too bad so few people really get to understand the real issue there...

[Guest SpaceRain]

Unfortunately the problem is not with the developers (they can use what they want to write into the raw frame buffer, they can you PocketHAL or their own routines). The problem os with the OEM: Will they give developer access to the raw frame buffer.

Those are the developers I meant, sorry should have made that more clear. I know there's not much we can do if they don't provide what you're asking for and we will be stuck with 14 ms screen updates instead of 8 ms.

[Guest The PocketTV Team]

Those are the developers I meant, sorry should have made that more clear. I know there's not much we can do if they don't provide what you're asking for and we will be stuck with 14 ms screen updates instead of 8 ms.

If will be more than 140ms instead of 8ms if you have to go through GDI...

[Guest SpaceRain]

Naw, it's 14 ms, I can get 71 fps on full screen updates on my E200 without using GAPI.

[Guest The PocketTV Team]

You mean without getting direct access to the raw frame buffer ?

We are not talking about GAPI there, despite what some people say. We are talking "direct access to raw frame buffer" (regardless how) or having to go through GDI.

You understand that, don't you ?

In order to use all the nice libraries that you like, PocketHAL and the like, you need direct access to the raw frame buffer. Is that clear to you ?

[Guest SpaceRain]

Hahaha, yes, that is clear to me, but that doesn't mean you have to use the slowest possible functions, like SetPixel(HDC, int, int, COLORREF). :)

[Guest The PocketTV Team]

Hahaha, yes, that is clear to me, but that doesn't mean you have to use the slowest possible functions, like SetPixel(HDC, int, int, COLORREF). :D

Yes, so it is clear to you that WM2003-SE could make it difficult and is some cases impossible to access the raw frame buffer directly.

If you think this is no big deal, then I wonder why you are interested by all that.

I don't think the problem will solve itself by using smilies and downgrading the consequences, really.

[Guest SpaceRain]

I didn't say it wasn't a big deal. I said we would be stuck with 14 ms updates instead of 8 ms updates. Obviously that leaves less time for everything else.

[Guest The PocketTV Team]

I didn't say it wasn't a big deal. I said we would be stuck with 14 ms updates instead of 8 ms updates. Obviously that leaves less time for everything else.

Do you access the frame buffer directly (e.g. through PocketHAL), or do you use GDI ?

[Guest The PocketTV Team]

Also, don't forget that most of the new WM2003-SE Smartphones will have a screen surface about double (in terms of number of pixels), so there will be about twice as much video data to move to the display...

And 4 times as much for the new VGA-res Pocket PCs.

This will just compound the issue...

[Guest SpaceRain]

Once again: GDI only.

[Guest The PocketTV Team]

Once again: GDI only.

Ok. For video intensive applications, e.g. PocketMVP and PocketTV, using GDI is out of the question, especially on those new hi-res devices...

[Guest SpaceRain]

All right, it's 14 ms (71 fps) for full screen redraws in 176x220x16 on E200 using just GDI, but I have no idea how much it is on other devices running at different speeds with different resolutions.

[Guest Arisme]

For the record, my GDI draws have been reported to be faster than GAPI draws on E800 devices (most noticeable in full-screen VGA mode).

But eh, I'm probably wrong again, as I'm completly clueless, and probably all my testers are too. Therefore I humbly apologize for wasting your Most Valuable time.

[Guest The PocketTV Team]

> For the record, my GDI draws have been reported to be faster than GAPI draws

I don't know what "GAPI draws" means, since GAPI does not draw anything...

GAPI does not have any routine to draw or copy bitmaps in the frame buffer.

[Guest SpaceRain]

That doesn't sound very likely, so maybe you're right that you're wrong this time. Then again, we were wrong last time, not you. :)

[Guest The PocketTV Team]

That doesn't sound very likely, so maybe you're right that you're wrong this time. Then again, we were wrong last time, not you. :D

What does not sound very likely ?

[Guest SpaceRain]

That he could do things faster with GDI than with GAPI.