Timothy Miller wrote:
On 6/1/05, Andy Goth <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hamish Marson wrote:
Admittedly text screens with LOTS of updates may run slower... But how
often do people run fast moving text displays?
Every time they do a scrolling directory listing.
I have a relatively slow display on my laptop (have to use VESA
drivers), but I only notice when I scroll a lot of text in a
vertically-maximized xterm. The rest of the time, things are peachy.
Good point. I hadn't thought of that.
But in his defense, if there are lots of blank spaces on the screen,
and they're in many of the same places before and after the scroll,
then it's not so bad. Of course, we can't always count on that sort
of thing.
The missed word here was xterm. Xterm doesn't use text mode in the
least. It is entirely graphics and uses X's text functionality.
However a good example would be scrolling through the X.org logs trying
to figure out why X won't start after some change. Or think about a
Gentoo or Debian install, or any install run in text mode for that matter.
It is actually a quite good idea though. The base frame rate is barely
affected with the addition of one more memory read, an xor, a
conditional jump and a conditional write. The added instructions are
only executed once for every pair of characters or 2000 times for an
80x50 screen. Whereas the shift and store operations in the blit loop
get executed around 3.9M (3.9 x 10**6) times per screen. So, if only
half the screen gets changed, you blit half as many pixels and
effectively double the refresh rate. In the best case such as when you
are typing on a static screen, the refresh rate would approach 1500Hz
barring any limiting factors elsewhere. The downside to all this is
that the refresh rate is no longer fixed and users would see performance
degrade as the screen got busier and busier.
I'm beginning to think this is all moot though. I'm really beginning to
believe that building the VGA core entirely in hardware is going to be
the faster and cheaper (in FPGA resources) method. However something we
all have missed here is that it doesn't matter if it is. All we need to
do is make our best guess and build it. We need working VGA from the
beginning of availability of the FPGA board. A lot of people have
presented good and in many cases novel ideas in this discussion. We
don't have the resources to determine up front which is the right way.
Once we have an FPGA in hand anyone who wants to try and prove why one
idea is better than the others and should be the final design is welcome
to change the core and see what happens. That is one of the great
beauties of our design approach.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
