delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/02/15/10:28:48

Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE3538051@probe-2.acclaim-euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Line frame buffer speed problem
Date: Mon, 15 Feb 1999 15:26:56 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Reply-To: djgpp AT delorie DOT com

Ludvig Larsson writes:
> The testvalues from SciTech Display Control Center:
>
> mode: 640x480x16bit: Banked
>
> Clr screen: 75Mb/sec
> BitBlt:     55Mb/sec
> 
> mode: 640x480x16bit: Linear buffer
>
> Clr screen: 21Mb/sec
> BitBlt:     19Mb/sec

That is _really_ weird. Sorry, I don't have anything especially useful
to suggest here other than to say that I've never heard of anything
like this before :-) I would have put money on these results being
due to something odd in your code rather than the video hardware,
but that doesn't make sense when you see the poor performance in the
SciTech test program as well as with your code, and when using a
totally different VESA driver...

The only possible explanation I can think of is that something else
is contending with the memory range that your card is using. Is 
there anything at all weird about your machine setup, ie. are you
using an unusual operating system or DPMI server? Try dropping out
to clean DOS (not a win95 box), disabling any disk cache or memory
management software, and running your program using CWSDPMI. Does
that make any difference?

Another possible thing to try, since you have a Matrox card, 
would be to install the FreeBE/AF Matrox driver from 
http://www.talula.demon.co.uk/freebe/, and try using that instead
of VESA. Of course this will require you to have some code that
supports the VBE/AF interface, but you can install Allegro and
use it's test program to check whether this helps at all, and
then borrow the code from Allegro's vbeaf.c file if you decide
to use this method. Most of the major VBE/AF speed improvements
come from things like hardware accelerated lines and rectangles,
but my Matrox driver also supports a hardware assisted blit from
system memory onto the screen, which works by sending data to
some card registers rather than directly to the vram, so this
could well help with your problem.

SciTech do also provide VBE/AF drivers for a lot of cards, but
the last I checked, they hadn't implemented any of the system
memory blitting functions on the Matrox, so my driver is the
only place to get that support.

> Well, so I have an old card, but do I need to make
> my library support LFB And Banked modes(as a commercial product)
> or is my card broken/to old?

It would be a good idea to do that in any case, if you are
expecting this program to be widely used. Linear framebuffers
are (usually :-) a lot faster, but a lot of people still
don't have hardware/drivers that support them. This is a
totally unscientific measurement, but judging by the email
I get from people using Allegro, probably about 25% of people
still only have VBE 1.2 drivers. This is compared to about
90% a couple of years ago, but it is still a significant
proportion of your potential userbase...


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019