This legacy article remains on the web site for historical and research purposes. For a list of current article by Jan Ozer, please click here:

Multimedia and Windows '95
All rights reserved © Doceo Publishing, Inc. 1995

This article analyzes Windows 95's impact on multimedia creation and playback performance. We ran a series of tests on a computer running WFW 3.11, loaded Windows 95 and then ran the same tests. The results were .... interesting. The results table is included, along with an explanation of Microsoft's shift from DCI to Direct Draw and the implications of that move on upgrade decisions. A must read article for those considering shifting to Windows 95 as their main creation, and especially playback platform. First published in CD-ROM Professional, August 1995.

Windows 95 - The Multimedia Platform

Top of Page

In the beginning there was DOS, and it was good, especially on low end computers. Many remember their first brush with Windows as a surreal slow motion experience, moving from a peppy DOS word processor to a Windows app that quickly fell behind a fast hunt and pecker.

In truth, Windows 3.0 took hold because the hardware finally caught up to the demands of the graphical user interface (GUI). But Windows' GUI is a double edged sword. The environment that enables WYSIWYG word processors also boggs down graphics and video performance, which limited Windows' success in one very strategic and fast growing market segment -- multimedia, and more specifically, games. Long after Windows dominated the corporate desktop, DOS was still king of the joystick. One of the very clear goals of Windows 95 was to topple its older sibling, and to finally move Windows to the top of the gaming mountain.

This article focuses on what Windows 95 brings to the CD-ROM publishing party from a graphics and video perspective. First we'll look at the short term implications for developers and end users, describing what to expect when you install Windows 95 on your current systems and use currently available software. Then we'll study the graphics, video and 3D architectures that debuted with Windows 95, describing how these will impact graphics and video performance in both the short and long term.

Windows 95 - The Short Term

Top of Page

The most fundamental change in Windows 95 is the migration from a 16-bit to a largely 32-bit architecture. We say largely because Windows 95 still contains 16-bit code where, in Microsoft's words, "16-bit code balances the requirements for reducing the size of the system and maintaining compatibility with existing applications and drivers." In other words, 16-bit code was used when 32-bit code would unreasonably increase program size or jeopardize compatibility with older applications.

In general terms, the 32-bit architecture increases performance over 16-bit much like a four lane highway can boost overall traffic throughput over a two lane highway. Architecturally, the system can handle twice the data in the same amount of time.


Fig. 1: Two primary components of Windows.
The change from 16-bit to 32-bit affects two key areas, the Applications Kernel and Input/Output Services (Figure 1). The Applications Kernel is where the operating system interacts with programs like word processors or games. While Windows 95 remains compatible with older, 16-bit programs, it delivers little or no performance boost with these "legacy" applications, which still send 16-bit data through the 32-bit highway.

To increase performance in the Applications Kernel, programs must be re-written to support 32-bit code. Thus core speed improvements in applications programs depends on how quickly your favorite programs and tools are ported to 32-bit code.

Happily, this is not the case with I/O Services, which contains device drivers between the application program and system resources like graphics cards, printers, hard disk and CD-ROM drives. In Windows for WorkGroups 3.1 (WFW), the most advanced Windows version prior to Windows 95, these drivers were 16-bit DOS programs. Microsoft ported these drivers to 32-bit Windows code in Windows 95, which boosted inherent performance, and eliminated the overhead associated with communications between the DOS drivers and Windows environment.

In theory, this makes the short term benefit of Windows 95 extremely application dependent. Data rich, display intensive programs like games and multimedia titles stand to gain more in the short term than less data intensive applications like spreadsheets or word processors. This is especially true given that Windows 95 ships with 32-bit Indeo and Cinepak codecs, delivering a decompression performance boost in application speed as well as I/O services.

To measure these changes, we tested WFW performance on a Gateway Pentium 60 with 16 MB of RAM, PCI bus Mach 32 graphics card, a double speed Mitsumi CD-ROM drive, an internal IDE 520 MB hard drive and an external 2 GB Micropolis AV drive. We used the latest SCSI drivers from Adaptec which enabled 32-bit access to the AV drive under WFW. Then we loaded Windows 95 and tested again.

The Envelope Please

Top of Page

We used two benchmark test programs to measure theoretical performance changes and then real world tests to determine how these advances translated to real user benefits. We first tested with Microsoft VidTest, which measures processor overhead associated with a specific I/O activity. Lower scores translate to more efficient systems, which should mean overall better performance. Then we tested with Ziff Davis' WinBench 95, which uses a number of discrete I/O tests to derive a raw score for graphics and disk performance.

VidTest revealed that Windows 95 32-bit graphics engine reduced processor overhead associated with graphics functions from 68% to 25%. Graphics WinMark95 scores confirmed this boost, with Windows 95 outperforming WFW by almost forty percent.

Fixed disk tests revealed similar performance boosts, with Windows 95's 32-bit hard disk drivers reducing processor load by over 30% for the SCSI drive and over 40% for the IDE drive. This translated to a 250% increase in Disk WinMark95 results. The SCSI scores were particularly impressive, since 32-bit SCSI drivers were used for the WFW tests. This really highlights the benefits of Windows 95's integrated 32-bit I/O system over an isolated 32-bit driver in WFW's 16-bit operating system.

Real world tests confirmed these benchmarks. In video capture tests, Windows 95 was about twenty percent more efficient than WFW, which means higher capture bandwidths and better looking video. Intel's new 32-bit codec compressed thirty three percent faster than WFW's 16-bit code, although Cinepak's compression time was unchanged. On the playback side, the combined effect of the 32-bit hard disk and display drivers and the 32-bit Indeo codec boosted display rates by 5 frame per seconds (fps) from both drives. The more efficient Cinepak played back at a full 30 fps on all benchmark tests.

Unfortunately, these same benefits did not extend to our double speed Mitsumi CD-ROM drive, where Windows 95 was approximately 50% less efficient than WFW. Why the performance hit? Where Windows 95's display and hard disk device drivers are completely 32-bit, Windows 95 includes both a 32-bit CD-ROM file system (CDFS) and the older 16-bit file system, MSCDEX, for CD-ROM drives like our Mitsumi that still uses 16-bit drivers.

When a 16-bit program communicates with a 32-bit program, it must "call" the program and translate the call parameters from 16-bit to 32-bit instructions. This process, called a "thunk," is extremely processor intensive, so much so that communicating between WFW's 16-bit I/O system and the 16-bit Mitsumi CD-ROM driver is more efficient than thunking between Windows 95 32-bit I/O space and the 16-bit driver.

We performed several tests to measure the real world effect of thunking. One class involved loading CD-ROM based applications and searching CD-ROM databases. Windows 95 was slightly slower than WFW in all but one test. Windows 95 was also 25% slower than WFW in Indeo video playback tests, despite the 32-bit Indeo codec.

It is important to note that SCSI drives will probably not be effected adversely, but rather only drives with proprietary interfaces that Microsoft couldn't produce 32-bit drivers for. Microsoft did confirm that thunking was the problem.

New systems shipped with Windows 95 will likely use 32-bit CD-ROM drivers and avoid this problem. However, since the vast majority of installed CD-ROM drives use 16-bit drivers, most are susceptible to the thunking slowdown. The extent of the degradation will vary by drive, and will immediately reverse if and when 32-bit drivers become available. At this point, it's unclear whether CD-ROM drive manufacturers will quickly come forth with 32-bit drivers for their older drives comprising the installed base.

The short term net/net? Video developers stand to gain the most from the low level architectural changes in Windows 95, with significant advances in both capture and compression performance. New Windows 95 systems with 32-bit CD-ROM drivers will also outperform a similarly equipped WFW system. However, the installed base could actually suffer a performance hit when upgrading to Windows 95 unless they simultaneously upgrade to 32-bit CD-ROM drivers.

In the medium to long run, most programs will port to 32-bit code and users will either obtain 32-bit CD-ROM drivers or buy new CD-ROM drives. Then the benefits of the new 32-bit architecture will really shine.

Windows 95 - Graphic and Video Architecture

Top of Page

Windows 95 also debuts a new graphics display Applications Programming Interface (API) that ultimately will boost video, graphics and 3D performance more significantly than its 32-bit architecture. Understanding the new API, and its short and long term implications, requires a quick walk down memory lane.

All DOS applications that display graphics write directly to the video hardware. Working with the various video cards was simple because video modes like EGA and VGA were standards that were implemented identically on all video cards. As video card capabilities expanded in non-standard ways, DOS developers had to write video card specific drivers to leverage the new functions. Driver support became nearly impossible as the sheer number of video card producers and non-standard modes increased.

Fig. 2: Windows GDI
Windows eliminated this problem through its Graphic Device Interface, or GDI (Figure 2). GDI uses a well defined, graphics format called the device independent bitmap, or DIB, as the medium of exchange between the applications program and graphics card. Rather than writing directly to the video card, Windows applications transfer DIBs to Windows, which uses a driver supplied by the video card manufacturer to convert the DIB to the video card specific format.

Since Windows applications don't write directly to the video card, video card specific drivers were no longer necessary. The downside was display speed. Writing directly to video hardware is much faster than negotiating the display through Windows GDI. While this isn't a problem for most business applications, it's a very significant burden on video intensive multimedia applications, and especially graphics intensive games like DOOM, Flight Simulator and similar programs.

Over the last two years, Microsoft made several strides towards minimizing this burden. First came the Display Control Interface (DCI), a joint Intel/Microsoft specification that allows codecs to write directly to the video card, avoiding GDI and boosting video performance by up to thirty percent. DCI also lets codecs -- including software MPEG -- access additional video acceleration functions on graphics cards such as scaling and color space conversion, which enables full screen 15 fps video on 486/66 computers and above.

DCI involves driver support from the codec and video card, but is transparent to the applications program. Thus DOS-like performance is restored without forcing the applications developer to write additional drivers. Announced in 1993, DCI support is now a standard feature for most graphics cards.

In 1994, Microsoft announced WinG (pronounced Win Gee), a specification that lets developers bypass GDI and write graphics directly to the video card, again without video card specific driver support. Microsoft reports that Id Software ported their Doom graphics core to WinG in two days, and that Windows performance now rivals DOS performance.


Fig. 3: Windows 95 Multimedia architecture, March 1995
Initially, Microsoft indicated that DCI and WinG would be directly supported in Windows 95, along with further advances to OpenGL, Microsoft's three dimensional (3D) API that similarly allows direct access to video card specific 3D acceleration features. The Multimedia Graphics Architecture presented in their March 1995 Windows 95 reviewer's guide resembled Figure 3, basically showing business programs working through GDI with all other applications avoiding GDI either through DCI or Microsoft's 3D driver.

However, on April 20, 1995, Microsoft announced Direct Draw, a new multimedia architecture that replaces both WinG and DCI (see Figure 4). Direct Draw was formulated in response to specific requests from the gaming and multimedia development communities and offers additional direct access to graphics hardware functions like texture mapping, overlaying, rotating and mirroring. By providing direct hardware access to such a broad range of graphics functions, Direct Draw practically achieves Microsoft's goal of creating DOS-like graphics and video performance under Windows.
Fig. 4: Windows 95 Multimedia architecture, April 1995

Direct Draw appears to suffer one critical short term flaw: the lack of backwards compatibility with DCI. Specifically, while codecs still write directly to the video card using the same calls, the programming interface for accessing video acceleration features like color space conversion and scaling are different. This means that a Direct Draw compatible codec can't access these features in a DCI-enabled video card without a new Direct Draw driver. Practically, this means that installing Windows 95 on a DCI-enabled computer could degrade video playback performance significantly.

Banfield, explains the new policy. "After listening to games and multimedia developers, we realized that the original DCI specification was ill suited for their needs. We had to make the tough decision to forgo complete backwards compatibility with DCI 1.0 to institute a new specification to enable the next generation of entertainment and video applications. We're working with video card and codec developers to make the changeover as painless as possible."

Banfield states that updated Direct Draw drivers for ninety percent of the installed base of video cards will ship with the Direct Draw development kit in September, and that Microsoft and the respective video card manufacturers will make these drivers available through the standard channels for new drivers like Compuserve, the Internet and bulletin boards. All the video card developers we spoke with confirmed these comments.

WINDOWS 95, THE LONG VIEW

Top of Page

In the long run, the DCI/Direct Draw changes will be but a blip on the multimedia horizon, especially if Direct Draw brings parity to Windows graphics and make Windows 95 the gaming and multimedia platform of choice. Video card and chip developers have pledged their support and will write new drivers as soon as the specification is finalized. However, the short term impact on DCI enabled computers could be dramatic, depending upon how Microsoft handles the migration from DCI to Direct Draw.

Since Direct Draw isn't scheduled to ship until September -- one month after Windows 95, it's clear that Direct Draw won't be available when (or if?) Windows 95 ships and August. If Microsoft leaves DCI in Windows 95 until Direct Draw is ready, the transition should go more or less smoothly. However, if Microsoft removes DCI support from Windows 95, as reportedly is the case, installing Windows 95 on a DCI-enabled computer would actually degrade video playback performance.

Overall, though, Microsoft is moving agressively in the graphics and video performance areas with Windows 95.

It isn't likely that the DCI/Direct Draw potential for trouble or the CDFS thunking with 16-bit proprietary interface drivers will be the only problems experienced by the new operating system. But what is also clear is that Windows 95 has put real muscle in the video and graphics systems, and this bodes well indeed for multimedia CD-ROM publisher.

            -- Jan Ozer 

Top of Page
Test Significance WfW Win 95 Analysis
Benchmark Tests
Microsoft VidTest - Display Processor overhead associated with graphics display functions (lower scores better) 68% 25% Win95 32-bit DIB engine is more efficient than Win 3.1
Microsoft VidTest - CD-ROM @ 150/300 KB/S Processor overhead associated with retrieving data from CD-ROM (lower scores better) 15.9%
33.4%
26.4%
52.2%
Win 95's 32-bit CD-ROM File system (CDFS) is less efficient on legacy drives without new drivers
Microsoft VidTest - CD-ROM @ 150/300 KB/S Processor overhead associated with retrieving data from CD-ROM (lower scores better) 15.9%
33.4%
26.4%
52.2%
Win 95's 32-bit CD-ROM File system (CDFS) is less efficient on legacy drives without new drivers
Microsoft VidTest - SCSI drive 300/600/ 1000 KB/S Processor overhead associated with retrieving data from SCSI external drive (lower score better) 22%
40%
67%
12%
29.4%
43%
Win 95’s 32-bit filing system is more efficient than Adaptec’s 32-bit SCSI Win 3.1 drivers
Microsoft VidTest - IDE drive @ 300/600 KB/S Processor overhead associated with retrieving data from internal IDE drive (lower score better) 41.7%
87.3%
29.2%
45%
Win 95’s 32-bit filing system is more efficient than Win 3.1’s 16-bit drivers
Ziff Davis WinBench95 Graphics WinMark 95
1024x768x8-bit
Tests the efficiency of the graphics subsystem at specified resolution (higher score better) 6.29 9.75 Confirms that Win95 32-bit DIB engine is more efficient than Win 3.1
Ziff Davis Workbench95 Disk WinMark 95 Tests the efficiency of the disk sub-system (higher score better) 195 495 Confirms that Win95 is more efficient than Win 3.1
Real World - Creations
Two minute capture test (30 fps raw capture) with Intel SVR Pro. Results are frame drop % and capture bandwidth Stresses disk subsystem to measure true impact of 32-bit storage information (lower drop frames better, higher bandwidth better) 62%/
1013 KB/S
50%
1343 KB/S
Capture was much more successful under Win 95, both from drop frame and bandwidth perspectives
Compress 45 frame file with Indeo (min:sec) Test 32-bit compression engine (shorter time is better) 3:33 2:18 Substantial decrease in compression time (35%)
Compress 45 frame file with Cinepak (min:sec) Test 32-bit compression engine (shorter time is better) 3:57 3:49 Minimum decrease in compression time (3%)
Real World - Playback
Indeo Playback CD-ROM 20fps 15fps "Thunking" decreased performance
(30fps file) SCSI 23fps 28fps 32-bit driver increased performance

IDE
(higher fps better)
17fps 22fps 32-bit driver increased performance










Cinepak Playback CD-ROM 30fps 30fps No change
(30fps file) SCSI 30fps 30fps

IDE 30fps 30fps

(higher fps better)







Load CNN Newsroom Global View (sec:tenths) Test overall responsiveness (shorter is better) 13.82 13.56 No significant difference





Load Computer Select Test overall responsiveness (shorter is better) 20.52 23.36 No significant difference





Perform Computer Select Search Test overall responsiveness (shorter is better) 4.36 6.88 No significant difference





Load TFPL CD-ROM Directory Test overall responsiveness (shorter is better) 10.56 11.47 No significant difference


Top of Page