Matrox Video Driver Bugs

The Matrox video drivers for OS/2 are, in general, very solid. By solid, I mean that they don't crash the system, they perform fairly well, and are generally all around good video drivers. However, as with any non-trivial software project, there are bugs. This page is to document some of those bugs. There are two goals in doing so:

Provide other OS/2 programmers with knowledge. If other programmers know about the bugs, we, as a community, can find temporary workarounds to the problems so we can still deliver high quality programs to OS/2 users.
Hopefully convince Matrox to fix these bugs in upcoming drivers.

First off, let me point out that I am using the 2.21.063 version of the Matrox drivers. These bugs may not exist in older versions and may be corrected in newer versions. If you find out that these bugs are fixed, please let me know so I can update this site.

Most of the bugs I know about in the driver relate to drawing to offscreen bitmaps. One of the private projects I'm working on involves a lot of drawing to offscreen bitmaps and that is how I discoverd some of these. However, my private projects are not the only ones affected. For example, in Mesa 2, if you create a graph, you will see a "missing" pixel in the lower left corner of the border if the "Cache Graphs" option is turned on. That is an example of a commercial program affected by the bug. Anyway, here is a list of bugs related to drawing in off screen bitmaps:

GpiBox with the DRO_OUTLINE option will miss a pixel in the lower left corner
GpiBox with the DRO_OUTLINEFILL option will miss pixels in all the corners EXCEPT the lower left corner.
GpiFullArc (and the other arc functions) with DRO_OUTLINE option misses 4 pixels around the elipse.
GpiFullArc (and the other arc functions) with DRO_OUTLINEFILL misses about half the pixels around the arc. It makes the arc look EXTREMELY bad.
GpiLine does not properly update the current position in the HPS to the end of the line. Workaround: call GpiMove after GpiLine.

There is also a bug in GpiFloodFill with the FF_SURFACE option set. This bug affects both on-screen and off-screen drawing. Basically, the Matrox drivers work fine if the surface color that it is filling is black or white, but it fails (however, the return code says it is successful) if the surface is any other color.

To demonstrate these bugs, I wrote a small little program that draws a little picture to both a bitmap (which is then blted to the screen) and directly to the screen. This shows the difference in the output. The exact same code is used to draw both pictures. You can get the code to veryfy that from here. You can also get the compiled program as an exe (20k) from here.

Running the program on my Chips and Technology notebook or my Mach 64 desktop yields:

However, on my Matrox Millenium desktop (yes, I have three computers), I get:

The picture on the left is drawn to an offscreen bitmap and then blted to the screen. The one on the right is drawn directly to the screen. As you can see, there is a big difference between the pictures. The flood fill that was supposed to turn the blue to green failed on the Matrox driver. There are pixels missing all over the place when the matrox driver draws offscreen.

<- Back to my homepage