I’m drawing using the XSnappingGuidelines and YSnappingGuidelines to sharpen the edges of some lines in my 2D model. The usage of these was not entirely obvious to me from the documentation. Here it is in short:

A horizontal or vertical edge that falls on a guideline is snapped to the nearest pixel. The line is then filled away from the snapped edge to the pen thickness, blending for non-integers.

Edges and guidelines are both double values, and neither needs to fall on an integer value for snapping to occur. This can lead to some interesting effects.

The top section of lines in the image to the right are all drawn with a pen of width 1.0. The bottom lines are drawn with a pen of width 1.5. The lines are staggered by 0.1, so they don’t fall on pixel boundaries.

The columns are as follows:

1. No snapping guidelines
2. Snapping to line y position + 0.2
3. Snapping to line y position
4. Snapping to bottom edge of line
5. Snapping to top and bottom edges of line

Option 4 is what we’re usually going to be looking for. This ensures that one edge is sharp, and all lines are drawn with consistent widths. In the case of integer width pens, this means two sharp edges. Of course this causes uneven spacing between lines, but that should rarely be this obvious.

Option 5 produces weird effects with the non-integer (1.5) pen; since both edges are snapped, the pen width is rounded to the nearest integer, and not consistently, resulting in lines with width 1 or 2. So this method makes the line thickness depend on the line position – probably not what you’re going for unless you want two sharp edges on a very thick line. 

Option 3 is what I would have expected to use; this causes the line to straddle the guideline. It always produces a symmetric line, and if the pen width is an even integer, it results in snapped edges

Option 2 is interesting; it causes the lines to draw consistently, although neither edge actually falls on the guideline. I’m not sure what the logic is here, and it seems that this could cause guidelines to affect shapes that they aren’t meant for.

Example project (Visual Studio 2008, .NET 3.5)

The tray icon that I created for my application looked like a dog next to all the other beautiful icons in my system tray. Look at the rough edges on the smiley face.

At first I thought that windows was choosing the wrong size icon for the system tray. My icon file has 32x32 and 16x16 icons, and windows was using the correct one in every other situation. Then I realized that the problem was loading the icon from my exe's resources. I was doing this:

mIcons(0) = New Icon( _ 
  GetType(MainForm).Assembly.GetManifestResourceStream("EventWatcher.EventWatcher.ico"))

When I should have been doing this:

mIcons(0) = New Icon( _ 
  GetType(MainForm).Assembly.GetManifestResourceStream("EventWatcher.EventWatcher.ico"), _ 
  New Size(16, 16))

The .NET icon object doesn't load the whole icon file, just one icon. So Windows never got a chance to choose the right one. By default, it was loading the 32x32 icon, probably just because it was first in the list.

I was creating a fancy new icon for a program I'm working on, and noticed that it sometimes wasn't displaying correctly. After a little testing, I determined that in certain situations, Windows XP does not correctly render partially transparent pixels in a 16x16 icon.

Sometimes pixels with anything less than full opacity are rendered as transparent. Depending on the icon and how it is drawn, this may be hardly noticable. But here is my test icon:

First is the Explorer thumbnail view, second is what the icon looks like in the list or details view - that's the correct rendering.

The icon is correctly upsized to 32x32 for the icon view in explorer, and native 32x32 icons don't appear to have any problems.

Lesson - minimize use of partial transparency in 16x16 icon formats.