rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) (06/07/91)
During the last time I tested several VGA cards using Tseng 4000 and Trident 8900 chip sets. I have tested all modes (if drivers were available) and did benchmark tests. I have tested the cards under Windows 3.0 and under OS/2 1.3 Presentation Manager. Especially I was interested in the 1024x768x16 drivers because 256 color drivers are much too slow to be usable and are not required for most purposes. For both chip sets I got the newest drivers from cica.cica.indiana.edu for Windows and the OS/2 drivers from a site in Finland. The OS/2 drivers were 800x600x16 and 1024x768x16 only for both chip sets. Now the results. All drivers&cards worked well under both environments. But the speed was different. What I was especially interested in was simple screen to screen bitblt's because users very often move Windows around on the screen and the speed of these moves is important. I was surprised by the speed of the OS/2 drivers. On my (not so fast) 24MHz 386 windows almost instantly moved to their new positions, nothing of the moving process was visible on the screen. This applies to both chip sets although the Tseng 4000 was a bit faster. Now, under Windows 3.0 the moving of windows on the screen is unbelievable slow in comparison to OS/2. This too applies to both chip sets although here too the Tseng 4000 is faster (significantly). Moving a window of about 700x450 on the 1024x768 display took about or more than a second (!!!) on both cards. One can view every scan line beeing copied. This was not a problem of my particular machine configuration or Windows 3.0 installation but occured on several tested machines. Has anyone an explanation for these big differences in window moving speed of these two environments? This is even more surprising as both are basically 16 bit environments and are based on similar technology. I am not talking about 20% or even 50% of speed difference but almost an order of magnitude! Kai Uwe Rommel /* Kai Uwe Rommel, Munich ----- rommel@lan.informatik.tu-muenchen.dbp.de */ DOS ... is still a real mode only non-reentrant interrupt handler, and always will be. -Russell Williams
aaron@jessica.stanford.edu (Aaron Wallace) (06/10/91)
In article <1991Jun7.100103.8975@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes: > >Now, under Windows 3.0 the moving of windows on the screen is >unbelievable slow in comparison to OS/2. This too applies to both chip >sets although here too the Tseng 4000 is faster (significantly). Moving >a window of about 700x450 on the 1024x768 display took about or more >than a second (!!!) on both cards. One can view every scan line beeing >copied. This was not a problem of my particular machine configuration or >Windows 3.0 installation but occured on several tested machines. > >Has anyone an explanation for these big differences in window moving >speed of these two environments? This is even more surprising as both >are basically 16 bit environments and are based on similar technology. > >I am not talking about 20% or even 50% of speed difference but almost >an order of magnitude! > >Kai Uwe Rommel I sent Kai mail suspecting that it has to do with a window-position grid and came up with a farily neat speed-up-Windows trick. Under the Control Panel desktop section, set the Grid Granularity to 1. This will cause all Windows to snap to byte-multiple locations. They'll seem to reposition much faster, at least on VGA-type displays. Why is it that the VGA has such a hard time moving windows to arbitrary horizontal positions when the Herc can do it as easily as anything? Still don't know if this is the OS/2/Windows difference, but it could be... Aaron Wallace
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (06/11/91)
How about a video board that has VRAM and a video scanning scheme that can alter the real time video scanning address sequence so that each window can be placed in whole in its own memory location (provided you have enough VRAM to hold all the windows in full) despite where it is displayed on the screen (which is simply WHEN it is scanned out). Coprocessors can still be used to do fast bit-blt type operations on the window contents, but with the advantage that it does not have to deal with the hidden portions of the window, and the windowing system would not have to also apply these operations to, or cancel, any backing store that might be used (e.g. X servers) since there would be no backing store. Each window can have its own private pallette and can even operate in its own modes. One window might be 32 bits per pixel while another is simply 2 bits per pixel. Imagine dragging a window smoothly across the screen while the image of the earth shown in it is rotating at the same time, with not even the slightest pause out of the system. The window position numbers would be updated while the coprocessor is rotating the earth image. The window shape can even be round. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
tneff@bfmny0.BFM.COM (Tom Neff) (06/18/91)
In article <1991Jun10.200019.24609@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >How about a video board that has VRAM and a video scanning scheme that can >alter the real time video scanning address sequence so that each window can >be placed in whole in its own memory location (provided you have enough VRAM >to hold all the windows in full) despite where it is displayed on the screen >(which is simply WHEN it is scanned out). I think this idea has BIG*TIME possibilities! -- Shut up he explained. ++ Tom Neff -- Ring Lardner ++ tneff@bfmny0.BFM.COM or uunet!bfmny0!tneff