Jeff Bezos Hawks the Kindle

It’s still not clear whether electronic books are the wave of the future or a consumer products cul-de-sac. Technology continues to improve, and there are certainly lots of good reasons for a device like Amazon’s Kindle to be the leading edge of a major wave of adoption. A few of the more obvious arguments include:

• Reduced cost of distribution. The publishing industry wastes a lot of money printing and shipping books, and because of historical practices, creates huge numbers of books that never even get sold. Not very green, and a waste of money.
• Niche markets that can be very well-served. For example, high school and college students can replace those 30-pound backbacks with a 30-ounce tablet-sized device.
• Removal of barriers to publication. The news and magazine businesses are being revolutionized by self-publication in the form of blogs. Self-publication is possible in the printed book world, but it is still a rather awkward process. Publication to electronic format is presumably a trivial problem.
• Integration of information resources. A device like the Kindle allows you to consult the Internet, written reference materials, and your personal notes all from the same device, making it a true information portal.

But consumer acceptance is a fickle thing, so we don’t know if these rational arguments are going to fly. And of course, every writer who reviews a device like the Kindle or the equally capable Sony Reader feels compelled to write something along the lines of “But I just can’t imagine forgoing the pleasure of curling up on my couch with a good book.” I’m sure that when Gutenberg introduced movable type there were millions of industry reviewers posting notes to their blogs saying “The uniformity of the type is just esthetically unpleasing - I love it when I recognize the script of one of my favorite transcribing brothers.”

And then of course there’s the Steve Job’s money quote on the subject:

“It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore, forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.”

So it’s really pretty hard to be sure just which way this is going to go.
(more…)

Windows Developer Magazine July, 2002

Back in March 1998, Tom Armstrong and I published an article in Dr. Dobb's Journal showing a technique for implementing transparent regions in bitmapped images. In those days, Windows developers had to roll their own transparency solution, and the path was quite arduous. Today, Windows programmers can render images with transparency using Microsoft's IPicture COM interface, which is considerably easier than the solution Tom and I suggested. It's an easy way to accomplish the same task - if you watch out for its single notable drawback

The IPicture interface is a good way to draw images with transparency today. In the future, you'll probably want to use GDI+, Microsoft's new GDI interface for C++ programmers. I'll show you how to convert the sample program to write cleaner code with GDI+, and discuss the improvements it brings to the table.

Transparent GIFs

When creating a GIF file, you have the option of designating one color in the image as transparent. This transparency feature is normally used to make it appear as if an irregularly shaped image is floating on the background. An example of how this can be useful is shown in Figures 1 and 2.

In Figure 1, two news articles displayed on a Web page have graphical icons that illustrate article topics. The users of this particular web site have the ability to change their personal settings to use a different layout, which changes the background color of the page. In Figure 2, a different theme is used to show the same articles.

In both Figure 1 and Figure 2, the background of the GIF file used to illustrate the article is transparent. Web browsers know that they need to let the background color show through in the transparent regions of the graphic. You can see that the browser deals with the transparency properly in both cases, with nice effect. A beige background in Figure 1, a white background in Figure 2, and in both the topic images float nicely above the background.

Figure 1 - Transparent GIFs on a light brown background

Figure 2 - The same GIFs on a white background

Loading the GIF File

Getting an external file into a format Windows can display can be a chore. Tom and I chose to skirt the issue in our original article by working with files stored in Windows' Device Independent Bitmap format. Although not a popular file format, it was one of the few that Windows was able to read and write without help from third-party libraries.

The situation has improved quite a bit since then. You can now use Microsoft's OleLoadPicture() function to load both JPEG and GIF files. Given the popularity of these two file formats, you might find that OleLoadPicture() covers all your needs in this area.

OleLoadPicture() loads data from an IStream object and stores it in an IPicture object. You'll find that having the data in IPicture format is quite convenient when it comes time to render it. However, the odds are good that you want to be able to load your data from a file, which is not quite the same thing as an IStream interface.

The easiest way I know of to get from a file to an IStream object is to simply read the whole thing into memory and then use CreateStreamOnHGlobal() to create an IStream. A fragment that accomplishes that is shown here:

At this point you have an IStream object ready for use, and all that remains is to make the call to load the IPictureobject:

Although the code isn't particularly elegant looking, it has accomplished the goal of reading a GIF or JPEG file into memory in just a dozen lines or so. All that remains is the task of drawing the code on the appropriate display.

The Drawing Part

In our original article, Tom and I presented a straightforward method for displaying bitmaps with transparency. It required the use of three bitmaps:

1. The background bitmap.
2. The bitmap to be displayed, with a known transparent color.
3. A special mask bitmap. The mask bitmap should have all bits set to zero in areas where the display bitmap is opaque, and all bits set to one in the areas where the display bitmap is transparent.

Displaying the bitmap is simply a matter of performing the following sequence of operations:

Output = Bitmap1 XOR Bitmap2 AND Bitmap3 XOR Bitmap 2

With just a little bit of work, you can see that the output will be a copy of the pixel from Bitmap1 in every position where the mask (Bitmap3) has a value of all ones. The output will be a copy from Bitmap2 in every position where the mask has a value of all zeros.

That's all you really need to understand in order to draw bitmaps with transparency in any sort of graphics environment. What made it into a long article in 1998 was simply all the plumbing you had to do in order to get the background bitmap, create the mask, get the display bitmap, and so on.

The good news is that Microsoft's IPicture interface can take care of all of the messy details here with one call to its Render() function. Once you have loaded the GIF file into an IPicture object, the snippet of code below is all you need to get it onto your display:

Note that the code shown here centers the image in the client window, which complicates things just a bit. It also has to deal with the fact that IPicture uses the HIMETRIC mapping mode, which I have to convert to the more convenient pixel measurements.

A First Pass

Pressing this code into service reveals one striking problem with the IPicture interface. Calling its Render() function with the intention of writing directly to your display window leads to a somewhat unpleasant surprise. It turns out that IPicture uses the standard algorithm I describe earlier to implement transparency. Unfortunately, it performs each of the three steps directly on the display, so you get to see each intermediate bitmap in the process. The four screen shots below show it in all its glory.

Figure 3a - Opening the file

Figure 3b - The background has been XORed with the image

Figure 3c - The resulting bitmap has now been ANDed with the special transparency mask

Figure 3d - After a final XOR, the image is rendered with transparency

This sequence might be interesting to the average DDJ reader, but the end users of your program are hardly going to want to see these three images flashing in quick succession across their screen. The flickering is barely noticeable with small images, but on slow machines, big images go through the painting sequence with painful precision.

The solution to this problem is straightforward. Instead of drawing directly to the screen, you can create an off-screen bitmap, have Render() draw to that bitmap, then copy the completed product to the display. Having done that, you'll find that not only is the flicker eliminated, but the drawing operation actually completes much more quickly.

An MFC routine that accomplishes this in conjunction with the rendering routine above is shown here:

You can see that it only takes a few lines to create the off-screen bitmap. The code above creates a bitmap of the correct size, fills it with the correct background pattern, then calls the rendering routine. Once that is done, all that is left is a BitBlt() call which copies the result to the screen.

The Sample Program

To demonstrate this, I created an MFC program named TransparentGif, forgoing the usual document/view architecture. Instead, I just paint the entire client background of the window with a pattern, the better to view the transparency of the loaded image.

When the program first starts up, by default it draws directly to the screen. If you are blessed with a sub-Gigahertz CPU, you should be able to see the flickering effect quite clearly when loading the sample GIF included with the source. I added code to force a redraw every time you click on the image, which allows you to see the effect in all its beauty.

You can then use the Options|Off Screen Draw menu item to switch to the use of the off-screen bitmap. A little sampling between the two should be enough to convince you of the value of the off-screen drawing technique.

Switcing to GDI+

Looking forward to the future, you might find that this task is going to become a bit easier. Microsoft has developed a new interface to GDI for Windows programmers called GDI+. The class libraries and supporting DLL for GDI+ are shipping as part of Windows XP, and can be installed as an add-on to Windows NT, 2000, 98, and ME.

The header files and import libraries required for GDI+ are part of Microsoft's Platform SDK. To get this SDK, you'll have to have to subscribe to Microsoft's MSDN program at the Operating System Level or better, which has a list price of $699.

You need to perform two installations to develop and test GDI+ programs: the Win32 Platform SDK and the GDI+ runtime files. Both of these can be found on your MSDN CDs or can be downloaded directly from the MSDN site The GDI+ runtime kit can also be distributed with your software, so your end users need no special licensing.

Additions to the project

I made a copy of the TransparentGif program, renaming all the files and classes so that the new project goes by the name TransparentPlus. I then set to work making the changes needed to use GDI+ as the graphics interface.

The first few changes are the ones you typically have to make when using a new library. I added an include of the master header file, gdiplus.h, to stdafx.h. This ensures that I have all the correct prototypes and class definitions. To make sure that the compiler was able to find the header file, I had to add the SDK include directory to the preprocessor settings for the C++ compiler. I used the default installation location for the SDK, so I simply inserted the path:

C:\Program Files\Microsoft SDK\Include

into the list of additional directories for the compiler.

All of the classes and identifiers in GDI+ are placed in the Gdiplus namespace, so I also added a using namespace Gdiplus; declaration to stdafx.h. In a larger project, I probably wouldn't do this; the use of explicit namespaces in the source would add readability to the code.

Likewise, the import library was in the default SDK directory, so all I had to do was drag:

C:\Program Files\Microsoft SDK\lib\GdiPlus.lib

into my workspace pane, thereby adding it to the project.

Startup code

GDI+ programs require a few lines of code for initialization, as well as a cleanup call. I added the following lines to the InitInstance() function in my application class:

This code is lifted cookie-cutter style straight out of the GDI+ documentation. The token initialized by the startup function is passed to the GdiplusShutdown()method when you are done using the library.

File Loading

As you recall, the file loading code in the standard GDI program was a real rat's nest. The hoops I had to jump through in order to load a file into an IPicture object gave a classic demonstration of an ugly Microsoft API.

I'm happy to say that someone working in API design in Redmond has seen the light in this area. Loading images is an order of magnitude easier with GDI+. Instead of loading into an IPicture COM object, GDI+ supports a C++ Image object. This requires that I change the type of CMainFrame::m_pPicture in the appropriate header file. I can then reduce the file loading code from the ugly mess I had before to this picture of simplicity:

This is a huge improvement, and by itself is almost worth the cost of the SDK.

Drawing

The drawing code with GDI+ is a bit simpler as well, mostly because the Image object uses pixels for measurement instead of the HIMETRIC units from IPicture. Other than that a simple replacement of the Render() function with a call to DrawImage() constitutes most of the work. The updated routine is shown here:

GDI+ makes my code look a lot nicer, and informal tests show that GDI+ renders a bit faster as well. Better yet, GDI+ is smart enough to avoid rendering all three steps directly on to the screen, which means you won't see a flash of the XOR'd or masked image.

Despite the speed of GDI+, I think you'll still find that you need to do this image rendering in an off-screen bitmap. Experimenting with the second test program shows that although you don't see intermediate images, you still get an annoying flickering as the image as drawn. Rendering off-screen eliminates that problem.

Conclusion

This article gives you a couple of different ways to effectively use transparent GIF files in your Win32 programs. For today, the IPicture interface does a pretty good job. When GDI+ rolls out as a standard part of Visual Studio, you'll probably want to switch over to it for your imaging needs. Either way, you've got good options that make things look a lot nicer than they did in 1998.

Links

Source for both demo programs

July, 2002

Update: Intel is no longer giving these libraries away for free - be prepared to fork out real money for this code. Does this render the information in this article useless? I don't know, add your comments below!

In this article I take a look at Intel's Win32 JPEG Library, and present a slide-show app I built to test it. I found it quite easy to render JPEG images using this library, and I think the demo code I provide will provide you with a good starting point for your own work. I'll also perform a short comparison of Intel's library against Microsoft's standard IPicture component, both in terms of performance and ease of use.

Intel's Performance Libraries

Not too many people are aware of the fact that Intel dedicates a substantial amount of energy to its software products. As you would expect, most of the software Intel creates is designed to pull through more hardware sales, not to generate revenue of its own. One good example of this is Intel's JPG Library.

Intel added the MMX instruction sets to their CPU chips starting with their 486 Pentium MMX processors. The MMX instructions are designed to speed up certain operations needed in multimedia applications. One of these is the Inverse Discrete Cosine Transform (IDCT), which is used to when decoding JPEG images.

Developers typically can't take advantage of extended instruction sets in products designed for a widespread market, because they can't count on their target machines having the correct extensions. Companies like Intel or AMD can still leverage their proprietary processor features by providing device drivers, browser plugins, or other components, but this doesn't completely satisfy their desire for market penetration.

For example, my sample slide-show program doesn't use operating system components to decode JPEG files, meaning I can't take advantage of the MMX instruction set without writing specific routines to detect the target processor type, then branch to one of two different decoders depending on the result.

Intel correctly figures that they can convince me to offer support for their hardware if they dish it up on a silver platter, and that's exactly what they do with their series of Performance Libraries. At this time, Intel is offering the following roster of libraries:

• Intel Integrated Performance Primitives - an abstraction layer for multimedia processing.
• Intel Math Kernel Library - linear algebra and FFT routines.
• Intel Recognition Primitives Library - code for speech and character recognition software.
• Intel Signal Processing Library - access to Intel CPU functionality similar to that used in Digital Signal Processors.
• Intel Image Processing Library - image manipulation functions, including filtering, thresholding, morphing, FFT, and DCT.
• Intel JPEG Library - encoding and decoding of JPEG images.

All of these libraries have processor specific routines for various families of Intel CPUs, and all have generic code that will also run on any standard Intel Architecture CPU.

What's the Catch

In a clear case of enlightened self-interest, Intel is making these libraries freely available to software developers. You will have to go through a licensing procedure to in order to redistribute the libraries with your products, but as far as I can tell there aren't any circumstances under which Intel will require payments or royalties.

Support is another matter, as you might expect. Intel's web site has FAQ material, known issues, and so on. Talking to a person will require subscription to a premium support service.

Where to go

You can find Intel's JPEG library on their Web site, www.intel.com, by following the links to
Products/Software/Performance Libraries. At the time this article is going to press, the direct link is at:

http://www.intel.com/cd/software/products/asmo-na/eng/perflib/ipp/index.htm.

The library has many of the niceties that you would expect from Intel. Figure 1 shows one of the first screens from the professional installation program, which naturally allows for a full uninstall as well.

Figure 1 - Installing the Library

As you install the library, you'll also see that it includes examples, white papers, documentation, and support for C/C++, Visual Basic, and Delphi.

Using the Library - an Example

I originally stumbled upon Intel's library while searching for a solution to a pressing problem. My friend Darrick Deel and I were intent on supplying some entertainment to a company shindig at Cisco's development offices in Dallas. We were going to act as roving digital photographers, snapping candid shots of our coworkers as they engaged in atypical mirth and merriment.

Our goal was to use a notebook PC and a projector to randomly display shots of partygoers during the event. What we needed was a slideshow
program that would randomly display JPEG photos from a directory tree. We were hoping for a program that would run in unattended mode, but would still be able to periodically scan the photo archive looking for new shots. This would allow Darrick and I to add photos across the network without having to break into the show.

Slideshow software is easy to come by. As Figure 2 shows, a simple search on a popular download site turns up literally hundreds of possibilities. A surprisingly large percentage of this software is either free or quite cheap.

Figure 2- Searching for Slide Show Software

Despite the bountiful selection of software, Darrick and I were suffering from the Goldilocks syndrome - nothing we tried out was just right. Following in an age-old tradition among programmers, I decided to reinvent the wheel. Having recently downloaded Intel's JPEG Library, I knew I had just the tool I needed to make a quick
job of it.

Using Intel's Library

The library ships from Intel with a pretty decent manual in PDF format, and a nicely fleshed out sample program called JPGView. The manual is full of code fragments that do a good job of illustrating the various features of the library. After reading the manual and examining the sample code, the process of displaying a JPEG image on the screen looked pretty straightforward:

1. Initialize the library.
2. Read the JPEG file header to get the basic image information, including size and color space.
3. Set up the various members of the data structure that will hold a Win32 Device Independent Bitmap (DIB.)
4. Read the JPEG image data into the DIB.
5. Display the DIB.

The first four steps here are accomplished in a single routine I wrote called CreateImage. This function takes an input file name as a parameter and returns a pointer to a JPEG_CORE_PROPERTIES structure, which is where the Intel library stores all its information.

The final step is done in the WM_PAINT handler for the program's WndProc. Since the first four steps create a fully functional DIB, all the WM_PAINT handler has to do is set up some parameters and draw the DIB to the output device context.

SlideShow

I put this knowledge together in an imaginatively named program called SlideShow. Although the code is built using Visual C++, it doesn't use MFC, so you should have good luck using the program with Brand X C++ compilers.

SlideShow starts off as a console program that takes a directory name as a command line argument. That directory name should be the root directory of your album of JPEG files. Slideshow then creates a full-screen main window, starts a five second timer, and proceeds to process the message loop.

Other than a little bit of glue code, the message handling routine for this program really only cares about two messages: WM_PAINT and WM_TIMER.

WM_TIMER

The main window of SlideShow gets a timer tick once every five seconds. It has three main jobs to do when this timer tick occurs:

1. If needed, reload the list of pictures to display.
2. Destroy the current picture object.
3. Create a new picture object.

SlideShow keeps a list of all the pictures it finds in the JPEG directory in a C++ vector named WindowData::picture_names. It also keeps an index of the next picture to decode in WindowData::current_picture. As soon as the timer handler is entered, it checks to see if the current_picture value is at or past the end of the picture_names vector. If it is, the current contents of the vector are erased and the picture directories are scanned for a new list of picture names. (Note that this happens naturally the first time the WM_TIMER tick is processed.) The picture names are randomized so the sequences aren't repeated each time the program is executed.

After potential maintenance of the image name list, it's a simple matter to delete the current image and create a new one. CreateImage,
described a bit earlier in this article, does all the processing needed to load the JPEG image into a Device Independent Bitmap. This new image is ready to be painted on the screen, and I force that to happen by calling the Windows API function, InvalidateRect(). This forces a WM_PAINT message to be sent to the main window.

WM_PAINT

The WM_PAINT message means it is time to paint the JPEG image onto the screen. I've characterized this as being an easy task since the image is now in a DIB, and examination of the WM_PAINT handler in Listing 1 bears this out.

The actual painting is done via a call to Windows API function StretchDIBits(). This routine not only copies the image to the screen, but scales it as well. There are a dozen or so lines of code that set up the call to this function. I scale the image so that it fills as much of the screen as possible without clipping any bits, filling any unused space with the desktop background color.

Figure 3 shows what this looks like on the screen of a PC. The program quietly paints a new random image on the screen every five seconds. The machine shown here is a modified I-opener, which runs Windows 98 and has full network access. With no cooling fan to create ambient noise, the I-opener is an ideal desktop photo album.

Figure 3 - The Slideshow in Action

Making Windows into Objects

If you are used to using MFC for all of your C++ projects under Windows, you might find this to-the-API program a bit different. One thing I did to try and make it a little more structured is to encapsulate the Window data in a C struct, which could just as easily be a class.

When the program first starts, I create a WindowData object, which contains all the information regarding the currently selected
picture, the list of file names, and so on. When the window is created, I stuff a pointer to this object into the GWL_USERDATA DWORD owned by the window. From that point on, every time I enter the WndProc I can get a pointer to the structure, eliminating the need for global variables.

Integrating with Visual Studio

The download package for this program contains a project file, but you may need to do a bit of modification after you install Intel's JPG Library.

First of all, the SlideShow.cpp file includes Intel's header file, ijl.h, as shown in this section of code from the source file:

Naturally, this file won't be in your normal include path. I take care of this by going to the Project|Settings dialog in Visual C++, selecting the C/C++ pane, then the Preprocessor category. You should then enter Intel's header directory in the Additional Include Directories edit box. If you take the default installation, your dialog will look like Figure 4.

Figure 4 - Configuring the Include Path

The project file I built for SlideShow includes the static library, ijl5l.lib. If you took the default path for Intel's install, you don't need to make any changes whatsoever. Figure 5 shows the path that is defined in the current project.

If you would like to use Intel's DLL instead of the static library, or if you chose a different install path, you'll need to delete the current library from the project. After deleting, use menu option Project|Add to Project|Files to add the correct library.

Figure 5 - The correct properties for the Intel Library in Visual Studio

Intel vs. Microsoft

There are any number of reasons you might choose to use Intel's library to display JPEG images. But what about Microsoft's solution? Does the standard distribution of Windows come with components that can perform just as well?

As it happens, Microsoft ships with a standard COM object called IPicture that shares much of the functionality with Intel's library. It not only handles JPEG files, but works with GIF, BMP, and other formats as well.

Ease of use

To get a handle on its ease of use, I reworked my SlideShow.cpp to use an all Micrsoft solution. The resulting program, SlideShowMS.cpp (available for download) shares the same structure, and is probably nearly identical in terms of structure and complexity. The major changes are:

• Microsoft's image data is stored in the IPicture component, Intel's is in a JPEG_CORE_PROPERTIES structure.
• Reading the file data requires two steps and a bit of coding for Intel. Microsoft makes reading easier with the simple OleLoadPicture function, but loses points for not reading from standard files. Setting up the IStream object Microsoft needs throws away any advantage they have in this area.
• I used a standard Windows GDI function to draw the Intel object to the screen. IPicture has a Render method that is somewhat easier to use and requires less setup.

After examining these points, I think you'll agree that there's no clear winner here. If all that matters to you is how much work you have to perform to solve your imaging problems, you can stick with your personal preference and not worry about making a big mistake.

Performance

When it comes to decoding JPEG files and rendering them to the screen, Intel's library stole the show. I ran the Slideshow program through a batch of 20 JPEG files that were mostly 1600x1200 pixels in size. My non-scientific test game the following performance results:

Intel's library seems to take Microsoft's time and cut it in half! It appears that Intel's attention to performance paid off. (Interestingly, I would have expected to see a bigger delta between Intel and Microsoft on the Celeron CPU, but was disappointed.)

I'm sure there are ways to tweak my SlideShowMS program to get better performance from Microsoft's implementation. But the point of this article is to look at an off-the-shelf solution for use by programmers who may not be graphics experts. And for a straightforward implementation, Intel appears to really deliver when it comes to CPU cycles.

What about IJG?

The JPEG file format enjoys great acceptance in the software world. This is due in no small part to the availability of the Independent JPEG Group's (IJG) source code. The IJG created a non-commercial source code package that has been used as a reference and/or library by literally hundreds of programs out there. It enjoys a great deal of respect for its flexibility and feature depth.

Intel knows that many developers have already integrated the IJG code into their products, so they have created a 26-page white paper that discusses what you need to perform open-heart library replacement. There are major structural differences between the two sets of code, so this isn't an exercise for the faint of heart. But it can be done.

Summary

I found Intel's library quite easy to work with, which is probably evident given the length of my sample application. While I didn't do too much objective performance testing, I was happy with the speed I achieved when decoding and displaying multi-megapixel JPEG files on various PCs.

My satisfaction with the library is certainly only enhanced by the absence of a price tag. Intel's JPG library is definitely part of my image processing toolbox, you might want to add it to yours as well.

Article Source Code

Remember when PC Magazine used to give away their utilities for free? Ah yes, those where the days. The earliest PC Magazine utilities were distributed as PC-BASIC programs printed up in the Utilities section, which made good typing accuracy an important skill. Eventually this was supplanted by electronic distribution via BBS and then the Internet. A lot of useful programs were thrown our way for free, and PC Magazine presumably bathed in good will and reflected glory.

Back in July, 2002, I wrote one of those free utilities for PC Magazine. CubeShow was a screensaver that featured a tumbling representation of a 3D cube, adorned with photos of your choice. Having never written a line of DirectX code in my life, it was quite an adventure, but I think I managed to produce something that worked and was popular.

Some of the more interesting problems involved with writing this utility were:

• Finding the right rotation parameters to achieve smooth animation
• Figuring out how to change photos on a cube fact only when it was hidden
• Keeping a photo upright as the cube rotated

A lot of fun!

Figure 1 - CubeShow in action

Links

CubeShow on PCMag.com
CubeShow download link

Recommended Reading

If you are interested in 3D Graphics Programming, the texts below are all excellent reference material. If you purchase them after clicking through on the links below, you'll be expanding your knowledge and supporting this site at the same time. Thanks. (Note: all links will open in a new window.)

Introduction

Implementing transparent ActiveX controls seems to be one of those programming tasks that is rapidly approaching FAQ status. The ability to display transparent GIF files in most popular Web browsers has apparently put quite a few developers into "me-too" mode. Unfortunately for programmers, Windows 95 and NT don’t provide much native support for the display of graphical images with transparent components. In this article, we provide a fairly simple set of steps that can be used to work around the shortcomings in the O/S. Using Microsoft’s Active Template Library (ATL) we develop an ActiveX control that will display a bitmap with a single transparent color. The control can be used with current and some past versions of Internet Explorer, Netscape Navigator (with the ScriptActive plug-in), Visual Basic, and most other ActiveX containers.
(more...)