#4 Expected Frame Rate

closed
nobody
None
5
2006-08-24
2006-02-22
Charlie C
No

Hi there,

I was wondering what sort of frame rate I should
expect to get on my pocket pc. I am using a hp hx4700.
Looking at the clear / render / swap timings (taken
from PaintProc in paint.cpp) both my app and the test
app seem to spend alot of time calling
eglSwapBuffers - about 110 milliseconds. This is by
far the biggest chunk of time for the rendering
cycle. Does this sort of execution time sound
reasonable or am I doing something wrong?

Cheers for your time

Charlie Cronin

Discussion

  • Hans-Martin Will

    Logged In: YES
    user_id=618887

    It just means that the hx4700 has an aweful implementation
    of the GDI blitter. If PocketHAL has better numbers on
    swapping the screen, you might want to hook that up into the
    surface class. I could help you with that, and you could
    contribute it back to the project... :-)

    - HM

     
  • Charlie C

    Charlie C - 2006-02-23

    Logged In: YES
    user_id=1133957

    Thank you for your reply. I have downloaded the PocketPAL
    stuff and compiled/run the firework demo. I get about 27
    fps which seems much more reasonable.

    To use the PocketPAL blitter I would presumably need to
    modify your drawing surface class - surface.cpp and
    include/use the pocketPAL stuff?

    If it works and it improves the frame rate then I would be
    happy to contribute it to the project.

    Would you prefer me to use the sourceforge mail rather
    than this support request page to contact you?

    Cheers again for your time.

    Charlie

     
  • Frank Verheyen, Walrus Graphic

    Logged In: YES
    user_id=1523493

    hi Charlie,

    I have been sniffing around the source code, and noticed
    too that there is a lot of time spent just swapping
    buffers. This simply turns out to be because the system
    HDC and BitBlt is used... which is pretty slow on most
    machines, phew.. I wonder how they can lose so much time
    just copying memory ;-). Frame rates of around 6 to 10
    fps result from this, which is pretty poor. Being a WinCE
    developer myself for years now, I've gained quite some
    experience in optimized ARM assembly, and use GAPI (the
    gx.dll, you know) quite a bit... I am planning to make a
    direct interface to GAPI for Vincent OpenGLES, to kick out
    the slow windows code.. (or rather, exist beside it).
    This should speed up things, I hope. With GAPI in 2D-
    applications, I've reached frame-rates ranging from 30 fps
    to 50 fps, purely swapping memory around on various
    machines, old and new. Of course, GAPI by itself won't
    make the rendering of polygons faster, but at least it
    will reduce the swapbuffers() time.
    Another thing I noticed through time, and always good to
    know: if you can use the system's memcpy() function, then
    definitely do so, since it is heavily optimised on most
    platforms. I've been checking this out thoroughly,
    writing my own ARM assembly high-performance routines,
    using all flavours of optimisation (ranging from loop
    unrolling to aiming at nice round memory-offsets, even
    trying parallel DMA-access using the UART chips together
    with the CPU, etc)... and memcpy() simply is the fastest
    answer... I could only reach the same speed or get close
    to it with various optimisations, but hardly ever beat it,
    using my optimized assembly. The reason for this is that
    memcpy() by itself is very well implemented on most
    machines, by the system guys that make the machines: you
    can trust them, and save your effort to omptimise other
    things. memcpy() definitely is the answer to quickly swap
    buffers, if you don't have padding at the end of each
    scanline (or if copying over the padding doesn't hurt).

    So... I'll continue revising the source of Vincent
    OpenGLES for a while before embarking on this project of
    making a GAPI-interface under-the-hood. In case anyone is
    interested to share some thoughts, contribute or steer my
    efforts in sourceforge to a public release (hmwill?), then
    please do so! (just mail me directly at frank@walurs.be,
    since I don;t visit this forum frequently)
    I would like to use GAPI directly, not using an in-between
    library like PocketHAL or GapiDraw, since better speed-
    gains can be optained going directly to gx. Also, I've
    know firms in the neighbourhood bumping into troubles when
    using GapiDraw, for example, when new (e.g. WinCE5)
    machines cam out and their old code didn't work anymore,
    because of bugs in GapiDraw... that's what you get if you
    rely on a third-party non-open-source library... GapiDraw
    is quite OK, but if you roll-your-own, you're still better
    off, and have more control over what happens.

    greetz,
    frank verheyen

     
  • Hans-Martin Will

    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks