From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 14 Aug 1998 14:08:52 +0200

Re: SVGAlib wrapper now actually works!

> : -----Original Message-----
> : From: Marcus Sundberg [mailto:e94_msu@elixir.e.kth.se]
> : Sent: Thursday, August 13, 1998 9:12 AM
> : To: ggi-develop@eskimo.com
> : Subject: SVGAlib wrapper now actually works!
> : 
> : 
> : The native X version of Dumb gives 15.8 fps in 640x480x16 on my 
> : box, and the SVGAlib version gives 14.4 fps when running in the
> : same resolution on our SVGAlib wrapper, running on the X-target!
> 
> 15.8 fps == 63.29 ms per frame
> 14.4 fps == 69.44 ms per frame
> diff.    ==  6.15 ms per frame
> 
> or at 200 MHz it's 1.23 MILLION cycles.
> 
> now let's re-do the math at higher fps:
> 
> 60 fps == 16.66 ms per frame
> + 6.15 == 22.81 ms per frame
> which is  43.82 fps
> 
> this is pretty significant loss of performance.

Well, there's nothing wrong with your math, just
the prerequisites...

The performance loss comes mainly from two facts:
1. Due to svgalib being synchronous and X asynchronous
   the SVGAlib wrapper make libggi's X-target call XShmPutImage
   20 times/s, while the native X version of dumb only puts the
   image 15.8 times/s. So at 60 fps the SVGAlib wrapper would
   actually be faster, as it still would only do XShmPutImage
   20 times/s...
   With the asynchronous version of the SVGAlib wrapper
   I just hacked up the performance loss at ~15 fps is even
   less.
2. The svgalib version of dumb does an extra memcpy() of the 
   display-data compared to the native X version.

One should also note that the SVGAlib wrapper is not meant for
software where the source is avalable, but for apps like Quake
which is binary only.

Open Source apps shuould be written for libggi, which will allow
them to run on all targets without any overhead at all if they're
properly written.

//Marcus