Other

Bitmap transparency nightmares at Microsoft too

While trying to find a workaround for the Visual Studio 2010 Beta 1 problem with command bitmaps in add-ins, and sick about the issue of transparency in Visual Studio, today I have taken a look at the Microsoft Visual Studio 2010 User Interface Guidelines that are available here:

Microsoft Visual Studio 2010 User Interface Guidelines
http://code.msdn.microsoft.com/VS2010UX/Release/ProjectReleases.aspx?ReleaseId=2743

It’s impressive the level of effort and details that Microsoft puts to get the Visual Studio interface right from point of view of “look & feel”.

But the thing that I would like to comment about is the section 11.01.01 “Creating High Color Artwork” and subsequent ones , which I have read with a mixed feeling of joy and horror: it’s incredible how many different ways to get bitmap transparency are used in Visual Studio:

  • Icons (with built-in transparency)
  • 24-bit bitmaps with transparent color RGB=255,0,255 (magenta)
  • 24-bit bitmaps with transparent color RGB=0, 255, 0 (lime green)
  • Any of the two previous at the same time
  • 24-bit bitmaps with transparent color RGB=0, 254, 0 (almost lime green).
  • 32-bit bitmaps with built-in transparency (alpha channel)
  • The bottom-left pixel (x: 0, y: height – 1. Which sometimes needs to be magenta too!
  • Code to make bitmaps transparent
  • Etc.

Then, do not use Microsoft Paint, it can alter the bitmap header and color table. When using Photoshop, do not click File \ Save. Do not click File \ Export. Do click File \ Save As. And be aware of copy/paste operations… BTW, any mention to Visual Studio resource editor?

All that explained, you find this little gem: “high-color artwork integrates seamlessly into Visual Studio 80% of the time. If you’re the unfortunate developer who falls into the 20% case, this section is for you.”

The section is 11.02.04 “Debugging High-Color Artwork”, where you are provided with some images (I’m still figuring out how to extract them from a IE-only .mht file) that you can use to diagnose your transparency problem against 7 different causes (including one that can put your bitmap upside down!), that can appear combined, and that can be something new…

If this is the scenario inside Microsoft Visual Studio, it’s no wonder that add-ins (which are not part of Visual Studio on the contrary to packages) have always problems in each new version of Visual Studio for the two only things that they need transparency: command pictures and toolwindow pictures.

All this mess is caused by a problem that was solved when VS.NET 2002 was developed:

“Historically, developers only had twenty colors to work with: base 16 and four shades of gray. In Visual Studio 2002 that increased to 255 colors; however, most artwork was left at twenty colors. Because of the twenty-color limitation, early developers were forced to get creative in their use of images and palettes.”

(it seems that they were too creative…)

and then:

“Even though high-color has been around for many years now, we still need to work to remove these historic hacks and assumptions.”

To the Microsoft Visual Studio Team: how about removing all them for this very Visual Studio 2010 version? Keep it really simple: either icons, or 32-bit bitmaps (built-in transparency in both cases). No more magic colors. No more magic pixels coordinates. Given that we are forced to change our add-ins to get transparency on each VS version, you could sacrifice backwards compatibility and get this fixed for good.