Multimedia Development under Microsoft's Visual Basic and Borland's Delphi
The purpose of this document is to discuss the relative merits of Visual Basic and Delphi, specifically pertaining to multimedia development under Windows95.
Author: Tom


All comparisons were conducted on the same machine (a 486/66, 32MB RAM) running Windows95. Windows95 has enhancements to improve graphical performance over Windows 3.1 and Windows NT. A goal was to reach an understanding of the new capabilities and limitations. The main features under consideration were video, sound, and graphic animation. The tests performed included multiple video interaction, sprite animation, large bitmap scrolling, and multiple sounds. Tests were also conducted combining these elements. This document will generalize the testing results. Specifics regarding the tests as well as the actual executables is discussed in a separate document.

General Considerations

Before the comparisons are made between VB and Delphi there are general considerations worthy of discussion that are common to both development tools.

Multimedia Programming

When developing applications rich in content, a couple of issues need to be tackled first. Probably the most important from the programming perspective is the role that the various media is to play. For a large number of applications, the multimedia content is a video here and there, some bitmap transition effects, and possibly a sprite animation. In these types of applications where the activity is minimal, the use of timing controls is usually adequate. Where more activity (and interactivity) is required, the usefulness of timers diminishes.

Timing controls are common in visual environments like VB and Delphi. Their purpose is to raise an event at a user-specified interval. The programmer can then set up a routine to process this event. This is particularly useful for sprite animation. A simple example is to have your timer event call a routine to display the next sprite frame. Reasonably smooth animation can be achieved by having a timer that will fire an event at least 10-15 times a second. As timers use system resources and as the number of timers present in an environment are limited, it is a good idea to have each timer control the activity of as many sprites as possible. Ideally, you would have no more than one timer active at any one time.

In applications that have a lot of activity, the use of timers is often inadequate. A situation to avoid the use of timers, for example, is when your application uses a scrolling background or has a large number of sprites. Timer events can be replaced with a loop that handles the animation. Besides the graphic processing, the loop must also make sure to process system messages. This ensures that the 'non-sprite' components of the application will continue to function normally. A typical animation loop would be coded as shown in the following psuedocode:

	while animation = TRUE do
		process system messages
		process next graphics frame
	end while

This type of loop alternates between processing system messages and handling the graphics. When each step can be performed quickly, no noticeable slowdown in response exists. Ordinarily, this approach spends most of its time handling the animated content while still enabling the user to get quick response to the other application events (button clicks, mouse movements, etc.). This approach produces applications that find themselves in the middle ground between traditional (non-multimedia) Windows applications and interactive games. The balance allows the programmer to handle graphics specifically (for performance) and stills allows for the control functionality provided in the visual development environment. Some of the testing results compare, qualitatively, the difference between an application built with this type of processing loop and one based on timers.

The previous discussion holds for animation-intensive applications that do not involve video. The choice is not as clear when video is to be integrated with large amounts of graphic processing. Like sprite animation, video spends a lot of time processing (decompressing) the next frame. When video and animation run concurrently, the struggle for CPU time becomes critical. Video playback is driven by it's own timer. Using timers to control your own graphics can lead to severe video problems. Depending on the amount of graphic processing that each frame performs, a timer interval of about 40ms can stop the video from playing altogether. That is, your animation timer effectively stops the video timer's messages from being processed.

Adopting the processing loop approach, however, is not always better. Since this approach alternates between system messages and graphics processing, spending too much time in either step will degrade the performance of the other. The success of the processing loop depends on the ability to quickly process each step. Without this, the result is poor video, choppy animation, or both.

Depending on the approach taken, animation or video playback will suffer to varying degrees. This is not to say that it can't be done successfully. Typically, a judgement will be made given the available hardware, the desired effects of the application, and the performance of initial prototypes. Also, as video codecs improve (and move to hardware) the CPU time spent processing video will decrease. Such improvements in video technology, as well as improvements in processing power, can only improve the performance of both approaches.

Media Control Interface (MCI) Issues

Besides video, multimedia development commonly employs other MCI-supported devices including sound in MIDI (.mid) and wave (.wav) formats. System capabilities restrict the flexibility provided in any environment that allows MCI-supported media. These restrictions affect the amount of media available at one time. For sound files, only one .wav can be playing at a given time. Any attempt to play another .wav will fail until the active .wav has finished and released the sound channel. The same is true for a MIDI file. However, a MIDI and a .wav file can both be played simultaneously. It was not tested but is reasonable to assume that sound from a CD or external sound source would obey the same behavior. AVI video has a similar restriction regarding it's sound track. Multiple .avi videos can be played at once, but only the video window with focus will have control of the sound channel. Switching between videos will transfer the sound between them. The .avi sound track also interacts with .wav files. A .wav sound can not be played if an .avi already has control of the sound channel. If an .avi is started while a .wav is playing, the video will be displayed but the accompanying sound track will not be heard. Even if the .wav completes while the .avi is playing, the .avi file will not acquire the sound channel, unless stopped and re-started.

Another restriction placed upon video is display location. For optimal playback, the video must be horizontally aligned on a 4-byte pixel boundary. (Meaning that the distance from the left edge of the display should be equally divisible by 4). If this is not the case, the playback rate could slow 2 times or more. Windows 95 and some applications actually shift the video during run-time to ensure that it lies along an appropriate boundary, but this can not always be relied on. For best performance, the programmer should ensure that this is always the case, instead of leaving it up to the system.

Visual Basic 3.0

Visual Basic 3.0 stands as one of the most popular visual development tools of recent years. Its success is based, in part, on its short learning curve, especially considering the alternative of Visual C++. Another factor of its success is the extensibility of VB through custom controls (VBXs). Virtually every useful type of control has been built. The VBX downside is that it is not trivial to build your own. They can not be built in the VB environment and typically are built in Visual C++.

Despite its convincing attributes, VB 3.0 is not the perfect development environment. Due to the fact that VB is interpreted, performance concerns can arise when comparing VB to a development tool that can build true executables. VB 3.0 code also depends on the VB run-time DLL (vbrun300.dll). This DLL is just under 400K and adds some bulk to distributable VB programs, especially simple utilities. VB 3.0 also lacks the benefits of an object-oriented tool. Common OO concepts like encapsulation, inheritance, and polymorphism are not part of the environment. This is not to say that VB doesn't enjoy code reuse or other OO benefits. VB is better thought of as object based and not object oriented. A lot of good insight into the object world can be gained from VB experience, but the true OO functionality is not present.

As relates to multimedia development, VB 3.0 is a solid tool. Despite is interpreted nature, the tests conducted showed VB 3.0's graphical performance always at least slightly ahead of Delphi. A possible reason for this fact might have to do with Microsoft's understanding of Windows95 and how to really push the graphic limits. Another reason might be that the graphic calculations performed in the demos were minimal. More computationally intensive programs would likely shift the performance edge to Delphi.

VB 3.0's standard timer control lacks the resolution to make it an effective tool for animation control. The availability of high resolution timer VBXs, though, as well as the ability to skip the use of timers altogether, makes this a non-issue when comparing to Delphi. Numerous VBXs also exist to enable other multimedia functionality such as transition effects and animation.

The tests conducted found VB 3.0 to excel at handling a lot of graphic activity. This reduces to the ability to handle a large number of BitBlts (bit block transfers) to on- and off-screen device contexts. The one major drawback to graphic intensive work in VB 3.0 is the familiarity the programmer must have with the Windows API. VB 3.0 provides an easy way to call API functions, but the programmer must still know what to do with them. The programmer must also contend with palette control. This becomes a problem if you need to integrate external content into your multimedia application. These aspects of VB 3.0 add a bit to the learning curve. The important thing to note is that these facts do not restrict the end result. Multimedia development in VB 3.0 adds some complexity over standard VB 3.0 development but the compensation comes in the resulting performance.

Visual Basic 4.0

VB 4.0 was released as the successor to the popular VB 3.0. VB 4.0 comes in both 16 and 32-bit versions. Improvements include enhanced OLE support (including OLE automation), class modules and collections. Almost everything else, especially the multimedia related components remain unchanged. The accompanying documentation places the OLE enhancements as the major improvement. With VB 4.0 embracing OLE technology, VBXs are on the way out. The 32-bit version of VB 4.0 will not support the VBX format. All custom controls must be in the OLE format (.OCX). This is a considerable drawback for many due to the large pool of VBXs available. The other major drawback is the size of distributables under VB 4.0. The OLE technology is linked tightly in VB 4.0. Any application created in VB 4.0, needs the supporting OLE DLLs, even if the program itself has does not utilize OLE functionality. Estimates place the low end size of a VB 4.0 distributable around 1.2MB.

VB 4.0 adds ease to OLE development. It is simple to integrate OLE servers (i.e. an Excel spreadsheet, a Word document) into an application. Microsoft's view of object orientation (and code reuse) seems centered around OLE objects. VB 4.0 also introduces the capability to easily create OLE servers. Minimal time was spent investigating OLE server development, but a simple example was created in little more than an hour. The environment lends itself well for these tasks.

Other improvements pertain to inclusion of some useful object oriented features. Class modules are introduced to provide encapsulation for code and data. Also added are collections. Collections enable objects to be grouped together. Collections simplify code as actions can be performed on the collection as a whole. These features help extend the nearly non-existent object orientation of VB 3.0. They provide good tools to aid in code simplification and reuse. Despite the improvements, lack of direct support for inheritance and polymorphism make VB 4.0's object orientation incomplete.

Multimedia performance and capabilities appear unchanged in VB 4.0. If anything, performance of VB 4.0 applications was slightly slower than their VB 3.0 counterparts. The lack of VBX support excluded the demos with timers from being run under the 32-bit version. No high resolution timer OCXs were found, though no considerable effort was spent to find them. As in VB 3.0, the programmer still has to get down into the Windows API for most graphic functionality. The results still make this a worthwhile effort.

Delphi 1.0

Borland's Delphi (ver. 1.0) combines the ease of use of visual development with the power of a compiled language. Initially, the visual development environment resembles VB very closely. What distinguishes Delphi is the native code object Pascal compiler used to build executables. The net result is compact, stand-alone executables that can run 10 to 20 times faster (Borland estimate) than interpreted p-code (i.e. VB). Delphi is an interesting hybrid between fourth and third generation languages. Delphi provides a lot of flexibility for the programmer. Applications can be developed in much the same way as VB, or the programmer can optimize with his own inline assembler.

The choice of object Pascal as the base language also aids the development process. Object Pascal is fully object oriented (inheritance, polymorphism, encapsulation) without some of the complexity of C++. It is a powerful language, yet is relatively easy for the novice programmer to pick up. With the assistance of integrated debugging facilities, problems are efficiently found. Additionally, support for OLE 2.0 and VBXs, extend the inherent functionality of Delphi.

Perhaps the most useful feature separating Delphi from the versions of VB is the ease of extending the visual component library (VCL). New controls can be coded (in Delphi) and added to the development environment. This process is surprisingly easy and straightforward. This is where the true object oriented nature of Delphi outshines the object based concepts of VB. Custom components (objects) can be developed in the environment and reused as easily as any other visual component. For the multimedia tests performed, a stationary sprite component (class) was built and added to the VCL. Later, a mobile sprite component (class) was added as a subclass of the stationary sprite class. This too was added to the VCL. This provides an efficient way to reuse code, as well as a simple way to develop powerful applications with the speed of a visual development tool.

Besides the simplicity of building new objects, Delphi has other features that assist multimedia development. The standard timer component has better resolution than that provided in VB. The resolution, though, is still not as good as available VBXs. Delphi also does an excellent job hiding a lot of the lower level graphics chores. For the tests developed in Delphi, palette switching was controlled without annoying palette flashes. Colors were not mangled as they were in VB (ex. if a video had a different palette than a bitmap). In addition to handling palette functions, Delphi wraps the Windows API calls in its own functions. The programmer can make calls to the API if necessary, but the demo applications showed minimal performance benefit in doing so.

Handling off-screen bitmaps is a good example of the difference between Delphi and VB in this regard. VB requires numerous calls to API functions to get device context handles, build and realize palettes, and set bitmap bits. This requires an in-depth knowledge of the API as well as system operation. The same process was handled in Delphi by declaring an object of the bitmap class and telling the object to load the appropriate bitmap file.

Unfortunately, the resultant graphic performance of Delphi (as experienced in the tests performed) was surpassed by VB. Most of the Delphi tests produced acceptable results, but when compared to VB, the difference was apparent. Despite this finding, Delphi's integrated visual environment, true object nature and extensibility make it a solid programming tool for all Windows application development.


Product currently in Beta testing. Not included in testing. Delphi32 enhancements (from Borland literature)
ability to share .obj files between Delphi and Borland C++ projects
full OLE support including:
OCX support (and the ability to subclass OCXs as well as create your own in Delphi)
automation control
automation server construction
improved compiler speed
faster, smaller executable files


As a group, the visual development tools discussed here provide just enough multimedia functionality to deserve consideration when choosing an authoring package. They are, however, not directly built for this purpose. Their strong Windows development features make them strong candidates for integrating multimedia capabilities into 'standard' applications. As improvements in video and processor technology continue, so too will the ability of VB and Delphi to deliver highly interactive multimedia applications.

For purely performance reasons, VB 3.0 tested the best. It is by no means the best programming environment but for producing smooth animation it does the job. The wealth of multimedia VBXs is also a definite plus. The downside of VB 3.0 pertains mostly to development environment. Lack of OO support and the need to use the Windows API (for graphics work) make VB 3.0 less desirable in the long run. VB 3.0 would be the choice when developing multimedia applications that are light on processing content (i.e. demos). Simple decision logic and event handling can be handled very well with a fair amount of graphic activity.

VB 4.0 performed slightly slower than VB 3.0 throughout the demos. It brings along the benefits of VB 3.0 with the major addition of OLE. Depending on the need for OLE integration, this is a good or bad thing. The OLE extensions allow OLE servers to be coded in VB fairly easily. The ability to use external OLE servers is even easier. The down side is that if the use of OLE in your multimedia application is not needed, you still carry around supporting OLE architecture, which adds considerable bulk to distributable applications.

The OO extensions added to VB 4.0, specifically class modules, attempt the enhance the reusability of code but the object nature is still lacking. The lack of access to VBXs (in the 32-bit version) is perhaps, the largest drawback. Many multimedia developers have adopted certain VBXs as part of the programming toolkit. Until these VBXs can be brought over into the new OCX format, multimedia programmers might find it best to stick with VB 3.0.

If it were not for its slower (and sometimes erratic) graphical performance, Delphi would be the clear choice for multimedia development over VB. The object Pascal base and the excellent, extensible environment make Delphi a capable development tool. Delphi also lightens the load on the programmer, handling palette operations and providing useful graphic functions the eliminate the need to call Windows API functions. Delphi has to be given serious consideration if the final application will involve a large amount of processing. For large applications needing basic interactive multimedia, Delphi is a very solid tool.

Demo Outline

Note: Comments are made comparing VB to Delphi 1.0. Demos were made under VB3.0, VB4.0-16 bit, and VB4.0-32 bit. Where applicable, differences in VB performance will be noted (ie. VB3.0 much faster than VB4.0-16 bit).

1) Bitmap Scrolling

- The purpose of this demo was to develop routines to scroll bitmaps that were larger than the window in which they were to be displayed. Specifically, a 1280x220 bitmap was set up to be scrolled within a 500x200 window. The horizontal scrolling provided by the application can be started and stopped as well as directionally controlled. Also included in the demos is the ability to change the number of pixels that the picture will scroll each frame. The demos written include versions with timers as well as without. Those with timers include the ability to change the interval of the timer.

The scrolling effect was created simply by initially loading the bitmap to an off-screen device context. To scroll, a section of the off-screen bitmap is copied to the display for each frame. Shifting the starting point of the copy routine creates the scrolling effect. This approach was preferred over creating the entire bitmap within a form (as a control) and then shifting it back and forth on the form.

VB comments:

Using the standard timer to control the scrolling was quite poor. The resolution on the standard timer control is around 56ms. This puts the interval between frames to at least 56ms. This provided scrolling that was broken and jittery. A high resolution timer VBX was found to reduce the timing interval. This provided very smooth scrolling. Even at higher scrolling intervals, the effect was solid. As one would expect, lengthening the timing interval introduces a noticeable jitter to the scrolling. A version of the scrolling effect was also written without using a timer. This produced the best scrolling.

Loading in the off-screen was not as trivial as it should have been. Code was used that decomposed the bitmap file, built and realized the new palette, and then set all of the bits in the device context appropriately. Knowledge of the Windows API was essential for this code.

Delphi comments:

Scrolling under Delphi was slightly less controlled than under VB. On random occassions, the Delphi scrolling application would hesitate and then jump to the appropriate frame. Performance for the standard Delphi timer exceeded that of the VB timer, but even so, performance was not as good as under the higher resolution timer VBX. As in VB, Delphi scrolling was smoothest when the timer was not used to control animation.

Overall, scrolling large bitmaps in the two applications was comparable, but VB definitely has the edge on consistent smoothness. Creating the off-screen bitmap in Delphi was considerably more straightforward. The process involved creating a bitmap object and calling a method to load the file into it.

2) Scrolling w/ Off-window Video

- This demo was designed to test the interaction between video and graphic animation (scrolling). A 970x324 background bitmap was used with the result displayed in a 400x324 window. A 160x120 video sat alongside the scrolling bitmap window.

VB comments:

Scrolling is acceptable at small scroll intervals but becomes uneven at higher steps (with the video playing). Starting the video while scrolling introduces a pause in the scrolling. The background bitmap and the video have different palettes. The video looks fine but the background bitmap looks nothing like the real image. Colors aren't even matched with the closest from the video palette. Versions of this test were built with and without the use of a timer. Performance was noticeably better in the version without the timer (smoother scrolling and better video playback). In the version with the timer, the scrolling and video performance vary oppositely as the timing interval was changed (a quicker timer leads to better scrolling and poorer video).

Delphi comments:

Delphi adequately handled the difference between the bitmap and video palette. It appeared that the background bitmap palette was used and that the video colors were matched up with it. The color looked fine on both the bitmap and the video. Performance of the demo controlled by the timer was quite poor. Scrolling was choppy and inconsistent. At low timing intervals, scrolling was improved, but the video would not play. This forced lengthening of the timing interval, which resulted in poorer scrolling. The test done without use of a timer performed very similarly to the one conducted in VB.

3) Scrolling w/ On-window Video

- The same demo as in above demo, except that the video is displayed on top of the scrolling bitmap.

VB comments:

Test ran similarly to VB demo 2. It appeared to run slightly better with the video on top of the background bitmap.

Delphi comments:

Test ran similarly to Delphi demo 2.

4) Scrolling w/ On-window Video

- The same demo as performed above with the exception of increasing the video's size to 320x240.

VB comments:

Performance slightly better than VB demo 3. VB still has problems handling the palette conflict. Another interesting note is that when the video re-appears (after being hidden), the entire video window is not re-drawn at once. Only the sections that have changed since the last frame are updated. Apparently, the code controlling the playing of the video window is unaware of when the window itself is exposed (and should be re-drawn).

Delphi comments:

Performance slightly better than Delphi demo 3. Delphi has the same quirk relating to video re-painting (see VB demo 4 comments).

5) Multiple Videos

- This demo was built to test the ability to play multiple video files at one time. Two 320x240 videos can be shown at one time, each in its own window. The videos were in .avi format. Multiple videos can be shown at once, but the sound track will only be heard on the first video to become active.

For this test, VB and Delphi perform similarly. Playback of both videos isn't of great quality but it is acceptable. When transitioning between the two video windows, the video losing focus will suffer a pause of a second or more. The video playing in the window receiving focus appear unaffected by the change.

6) Multiple Videos

- Another demo to test multiple video interaction. For this test, two 320x240 and two 160x120 videos (.avi format) were shown in one window.

As in demo 5, performance between VB and Delphi was similar. Running two videos at one time produced adequate results. Playing three or four at one time resulted in noticeable frame skipping, particularly in the larger video windows.

7) Stationary Sprites

- For this demo, stationary sprites were animated on top of a scrollable background. The demos utilized the scrolling framework built in demo 1. The addition of sprites was made onto the off-screen bitmap and the resulting bitmap transferred on-screen. The code assumes that the sprite information will be contained within a single file. That file has the sprite frames next to each other, with the respective mask below each sprite frame. A control was added to enable the user to start and stop animation.

VB comments:

VB provided excellent animation for the sprites, even while scrolling. This test was only conducted using a timer. It's performance was very good with three stationary sprites. Additional sprites can be added at the cost of increasing the timing interval. As additional sprites are added, performance suffers to the point of the application not starting properly. Increasing the timing interval corrects for the start failure, but degrades the sprite animation.

Delphi comments:

Delphi appeared unaffected by the addition of sprites to the scrolling demo. Scrolling is still prone to occassional glitches, but sprite animation is quick. The major advantage of Delphi for this demo is the relative ease in which a stationary sprite component can be constructed. It involved less than three hours to design, code, and test a simple sprite component class. The class was then added into the component library to simplify creation of multiple sprites. This is a decided advantage over VB. As in VB, this test was only built using a timer. One would expect better performance without a timer.

8) Moving Sprites

- This demo is similar to demo 7, with the addition of the ability for sprites to move along the scrollable background bitmap.

VB comments:

VB handled multiple mobile sprites very well. There was no noticeable performance impact between one sprite and several (>5) sprites. VB still able to support solid scrolling while sprites are active.

Delphi comments:

Sprite animation was handled well. Scrolling ability suffers with larger number of sprites (>5). As in the previous demo (#7), a class was easily constructed and added into the component library. A mobile sprite class was built as a sub-class of the stationary sprite class. With this class (component) it is trivial to add additional sprites to a project. This extensibility helps ease the fact that Delphi performance still lags behind VB.

9) Integrated Sprites

- This test combined stationary and mobile sprites onto a scrollable background. An effort was made to determine the maximum number of sprites that could be controlled while still maintaining acceptable performance.

VB comments:

The demo is an excellent showcase for the graphical superiority of VB. Tests were run with and without timers. Simple collision detection was also added to the sprite processing logic. The demo without a timer again outperformed the one with a timer. VB handled over 13 sprites with no flashing or scrolling problems. A strange 'fuzz' was present on the background bitmap of the version without the timer. This 'fuzz' was removed as the sprites moved about on the background. This appears to be another palette problem under VB. Despite this, the animation and scrolling were excellent.

Delphi comments:

Performance was weak and limited to 5-6 sprites at one time for the demo built using a timer. The timing interval plays a larger role in performance as more sprite activity is used. Scrolling was very choppy. Delphi also had a slight problem mapping the colors appropriately. The sprites appeared correctly, but the background bitmap had a couple of its colors mapped incorrectly. The colors that were not correct weren't even close to the color they should have been. Throughout these tests, more graphic activity leads to greater performance gains when timers are removed from the application.

The test built without a timer was significantly faster than using a timer. Additional sprites were handled by this version with reasonable sprite performance as well as solid scrolling. Palette problems existed in this version. When the sprites are not animated, the colors appear normally. Whenever the sprites are animated, the background bitmap loses the proper mapping of its colors. This problem was a surprise as Delphi had handled prior palette conflicts without a noticeable problem.

10) Integrated Sprites and Video

- This demo is that same as demo 9 with the addition of a 320x240 video window on top of the scrollable background.

VB comments:

This demo was only built without a timer. The addition of a video window greatly slows down the graphic processing (scrolling and sprites). Another concern is that whenever the video window is stopped (or the video completes), the graphic activity speeds up greatly. This is simply due to the fact that when not using a timer, the graphics are processed as quickly as possible.

Delphi comments:

Not completed yet.