🚀 go-pugleaf

parry@yoyo.cc.monash.edu.au (Tom J Parry) writes:

> Ola Sigurdson (d89os@efd.lth.se) wrote:
> 
> > The above may be true, but it isn't the main reason for the slow
> > scrolling in the command windows. The problem is, I think, that
> > the window client code is inefficient to the point of being broken:
> > When the window scrolls up one line, each line is redrawn separately.
> > (The correct way to do it is of course to bitblt the window one line
> > up, and then draw the bottom line.)
> >   As an example, compare the scrolling speeds for the System Editor and
> > a command window, using similar fonts. You should find that the
> > scrolling is quite acceptable for the System Editor, and that it is
> > atrocious for the command window (even with coprocessed graphics).
> 
> Another aspect is the fact that OS/2 seems to use software emulation of the
> superior hardware features of these cards instead of the hardware code. In
> a DOS box you can turn off VIDEO_ROM_EMULATION and I got a 5 times
> improvement in scrolling speeds but my OS/2 windows are still far too slow.
> I have developped the habit of entering 'cls' before _every_ command I
> execute - and this actually saves me time!!!!
> 
> This applies both to the built in SPP SVGA ET4000 support and the 'leaked
> trident' generic drivers on my ET4000.
> 
> -- 
> Tom J Parry.
> Your reality is a figment of my imagination.

 
With the old 16-bit Generic ET4000 drivers, my scrolling speeds were 
actually phenomenal.  Now, that I'm using the TSENG 256 color drivers, 
I've since switched to many "full-screen" modes rather than windows.  In 
fact, WPS has just become my glorified task switcher.  
 
Regardless,  one reason OS/2 "emulates" video is due to the fact that 
many video cards for PCs use real-mode entry points which are 
incompatible with OS/2 - thus forcing the emulation to be active. 
 
Matt

s

mstaben@comtch.spk.wa.us
 
[Made in America]