Tony Schreiner's WebLog : Random

The Inline Returns Option

tonyschr — Thu, 26 Jan 2006 23:03:00 GMT

Using my last example, Stuart Ballard pointed out that using inline returns is another way to avoid the uninitialized variable mistake:

if (hwndParent != NULL) 
{ 
    if (fFoo) 
    { 
        return DoOperationWithFoo(hwndParent); 
    } 
    else if (fBar) 
    { 
        return DoOperationWithBar(hwndParent); 
    } 
} 

return whatever_the_default_return_code_should_be;

This is true, although whether to use inline returns vs. the structured programming technique of one entry point and one exit point is a separate consideration. :-)

Inline returns (and even exceptions) are usually fine as long as you are using a language with garbage collection, such as C# or Java, or you religiously adhere to the RAII technique (using smart pointers and such). However, in many programming environments where you're still manually managing resources: memory, reference counting COM objects, critical sections, registry and file handles, etc., inline returns can be dangerous. We use RAII quite a bit in our code, but not enough yet to reliably switch to the model of inline returns, so I didn't even think of mentioning that in my original post.

(There's also something to be said for being able to rewind the instruction pointer and step through code again while debugging, something that's made easy with the technique of one entry point and one exit point.)

More Micro-optimizations

tonyschr — Thu, 26 Jan 2006 07:17:00 GMT

Here's another micro-optimization that I'm not very fond of. I should note that we don't really obsess about these things too much internally - in general we have established coding practices and only occasionally debate a few debatable things, usually on the fringes. But they do make reasonable blog fodder and I'm trying to cover ones that haven't been debated ad nauseam.

HRESULT DoSomething(HWND hwndParent, BOOL fFoo, BOOL fBar)
{
    HRESULT hr;

    if (hwndParent != NULL)
    {
        if (fFoo)
        {
            hr = DoOperationWithFoo(hwndParent);
        }
        else if (fBar)
        {
            hr = DoOperationWithBar(hwndParent);
        }
    }

    return hr;
}

Catch the bug? This one's so obvious I'm not going to wait a day: if "hwndParent" is NULL then "hr" is left uninitialized. The micro-optimization here is that not initializing "hr" up front potentially saves a few instructions. The argument is that code size is one of the most critical factors for application performance on a heavily multitasking modern desktop (which is true; nearly all of our code is compiled for minimum size rather than maximum performance) and that this helps because it all adds up. The fix for the people who do not prefer initializing up front is to add "else" clauses to set "hr" to the correct error values. You may guess that with that fix you end up with a similar total number of instructions (or even more in this example), but in many cases initializing up front is certainly redundant.

The counter argument, of course, is that the risk of using uninitialized variables far outweighs the minor performance increase. This is the school of thought that I subscribe to.

The counter-counter argument is that modern compilers are likely to pick this up, and even if they don't our more advanced static analysis tools will.

The counter-counter-counter argument is that I've personally fixed around a dozen bugs in other people's code over the years that were the direct result of doing this, and it's also annoying when stepping through the debugger and seeing garbage values. :-)

For the most part this debate can be skirted by doing what I consider a C++ best practice:

HRESULT hr = DoSomething(hwndBlah, TRUE, TRUE);

That is, reducing the scope of variables as much as possible and avoid splitting initialization from assignment. However, in the above contrived example this isn't really possible.

The Risk of Micro-optimizations - follow-up

tonyschr — Wed, 25 Jan 2006 00:05:00 GMT

In yesterday's post I gave an example of a bug where an attempted micro-optimization combined with a common C++ idiom causes a fairly subtle bug. For those who didn't look long enough to catch it, the flaw was in these two lines:

BOOL _fRaining:1;
_fRaining = (dwFlags & WEATHER_RAINING);

The assumption that the coder was making was that he could save memory by only using a single bit for the boolean value, whereas BOOL is typedef'd as an "int" and will take 32 bits (on a 32-bit processor). As I pointed out in the post, this was an object which would have very few instances (in my real-world case it was tied to the top-level window of an application), so the most this could even theoretically save is a handful of bytes.

The bug is that "(dwFlags & WEATHER_RAINING)", which is a common way to check whether a flag is set, gives 0x02 as the answer, or 00000010 in binary. When this value is assigned to _fRaining, which is only a single bit, the value is truncated and only the least significant bit is kept: the 0. Therefore, _fRaining is set to FALSE.

In the comments, Rick Schaut pointed out that using "(dwFlags & WEATHER_RAINING) != 0" is more correct. This is true and would have avoided the bug. Mike Dimmick also pointed out that the compiler is going to round up to a whole byte (at minimum) anyway, and even then it's unlikely that you'll see any performance benefit due to the way processors access memory.

There are certainly scenarios where it is useful to carefully pack variables into a struct or class to save memory or bandwidth, but, like most micro-optimizations, in most cases it more likely to cause bugs than have any tangible benefit.

The Risk of Micro-optimizations

tonyschr — Mon, 23 Jan 2006 23:28:00 GMT

A lot of things have been said over the years about premature optimization, and after running into the following bug I thought it served as a good example of a type of premature optimization that I call "micro-optimization". That is, doing something quirky in order to save a tiny amount of RAM or CPU cycles. More often than not these quirks lead to bugs and less maintainable code, with no actual performance increase.

The following bug was in a class in an application designed to run on a modern desktop, and there would only be a few instances alive at any one time (say, 1-10 typically, maybe 100 in edge cases), so the amount of memory saved was negligible (if any).

This is a rather easy "spot the bug" exercise so I won't give it away. ;-)

DWORD WEATHER_SUNNY   = 0x0001;
DWORD WEATHER_RAINING = 0x0002;

struct CWeather
{
    BOOL _fRaining:1;

    CWeather(DWORD dwFlags)
    {
        _fRaining = (dwFlags & WEATHER_RAINING);
    }

    BOOL IsRaining()
    {
        return _fRaining;
    }
};

int main()
{
    CWeather weather(WEATHER_RAINING);

    if (weather.IsRaining())
    {
        cout << "It's raining!" << endl;
    }
    else
    {
        cout << "It's not raining!" << endl;
    }

    return 0;
}

Note: Depending on your compiler, if you crank up your warning level high enough you should get a warning for this. (Although curiously I didn't with VS 2005 and /W4).

RAW Conversion and Photo Manipulation

tonyschr — Tue, 17 Jan 2006 11:12:00 GMT

Last fall I purchased a digital SLR: the popular (and relatively inexpensive) Canon Rebel XT. I had been dabbling with digital cameras for a few years and was having increasing amounts of fun using the limited manual controls of my Canon S50.

As a technical person part of the draw is simply learning about the equipment, and in particular how to quickly adapt to various shooting conditions by changing the ISO, shutter speed, depth of field. Then there's the gadget factor with being able to choose from a variety of lenses (and flashes, etc.), often with difficult trade-offs. Oh, and it's funny how my personal taste often tends to drift towards "pixel peeping": the sharpness of the part of the subject I had intended to be in focus, the bokeh, the dynamic range, etc., sometimes at the expense of the subject. :-) I've done this forever. Back when I was an Amiga user I would find pictures that exemplified what the Amiga could do, also ignoring the subject ("Look, isn't that a high quality image!").

With this in mind, I find it fun to shoot almost exclusively in RAW and later post-process all of the images. After searching around and trying out various pieces of software I've converged on three main photo-related applications:

pixmantec RawShooter Essentials

This is an excellent RAW processing application and is available for free download. There's also a premium version available for a reasonable price.

RawShooter is great for going through an initial large batch of photos, flagging and categorizing the ones worth keeping, doing initial adjustments, and converting to JPEG. It is fast and has a pleasant real-time preview of most of the operations, and the output is reasonably high quality. The application is multithreaded so that you can queue up images and have it convert them in the background as you continue to sort and adjust. Overall I highly recommend this app, with only a few minor caveats:

The sharpening / detail extraction algorithm sometimes creates what I call a "watercolor" effect on parts of the image that are out of focus. This effect seems to be atypical of most sharpening algorithms and sometimes occurs even with very low sharpening (too low, given that RAW files generally need some sharpening).
The workflow is great, the engine is good, but parts of the UI are a bit quirky. This isn't a reason to not use RawShooter, but a bit of polish could go along way.

So far I use RawShooter for most initial conversion and I highly recommend it. However when I have a really good image I reach for...

Adobe Photoshop CS2

Due to the price, and the fact that I'm not a professional graphic designer, photographer, or any of those things, I had been hesitant to take the plunge. However, there is such a community around Photoshop that if you want to participate in certain graphics forums, read books, learn tips, share Actions, and generally have the best tool available, it's almost unavoidable.

Photoshop's Camera Raw plug-in is more cumbersome to use than RawShooter, but gives more control and (in my experience) higher overall image quality. In particular, the "watercolor" effect isn't present, and it's nice to have Curves (which are available in RawShooter premium). It's also nice to import the files directly into Photoshop to do additional post-processing while keeping the higher dynamic range. I've saved at least a couple of blown out skies this way (and without going overboard on post-processing either).

The downside of the Camera Raw plug-in is that it's relatively slow and so far I haven't found it effective for converting many images in sequence. When combined with Adobe Bridge it is capable of batch processing, but for me RawShooter is still better for the initial culling and conversion steps.

Once I've converted and finished post-processing I reach for...

Microsoft Digital Image Suite 2006 Library

You knew there had to be at least one Microsoft product in the mix, right? :-)

After trying a variety of photo managers I found that our product was best for my needs. It's fast and great for cataloging and rating pictures. The latest version's built-in image viewer is pretty good as well. It doesn't require any kind of custom directory structure or try to rearrange my images and otherwise complements the OS. For me the fact that it looks and feels like a normal Win32 application is a bonus; I'm not a fan of skinned UI with nonstandard behavior unless there's a strong justification.

Bug Triage

tonyschr — Thu, 12 Jan 2006 23:08:00 GMT

Eric Sink has a good article on the process of triaging bugs. In it he pokes a little bit of fun at the people who don't understand why all good software ships with known bugs and then discusses a process for determining which ones to fix.

Determining which bugs to fix and how to prioritize them is often a challenge, particularly for bugs in the middle of the severity/frequency ranges. There's no objective algorithm, so as Eric's article suggests it often boils down to a couple people discussing the bug and making the call.

However, there's another subtlety: certain classes of bugs often have strong advocates, including external teams tracking metrics and driving to get those bugs fixed. This puts extra weight behind those classes of bugs, which can be both a good thing and a bad thing. The good part is that in general these are severe bugs which the team would to fix anyway, and the metrics and pressure to get them fixed helps ensure that the team is shipping a product with known high quality. However, the downside is that this removes some amount of control (both consciously and subconsciously) from the product team, which can sometimes result in the wrong bugs getting fixed.

As an example, let's imagine that there are two bugs open, and the team only has time to fix one of them before a beta release ships:

1) Crash

2) UI element doesn't behave quite right

Crashes are a class of bugs which always rank extremely high on the priority scale, are tracked by metrics, and have strong advocates to get them fixed. In the absence of other information someone triaging these bugs will almost certainly rank #1 as a higher priority bug than #2.

But wait a minute: there is more information. The crash only happens in an obscure feature, and has only been observed while stressing the product using automated tests. There is no known way to manually reproduce the crash (the people who work on the feature can't get it to crash on demand), the fix isn't straightforward, and it doesn't appear to be a security risk. The fix might even be risky, or mask a more serious bug. Furthermore, suppose the UI element is in a high-profile feature, and that feature not behaving correctly will grate on the beta tester every hour that they use the product.

Now which bug do you fix? Clearly you fix #2.

This becomes obvious once you have enough information to make an informed decision, which is the key. Bugs cannot be triaged blindly by objective criteria; they must be judged by people that are not only familiar with the product and feature, but also have sufficient information about the bug to make an informed decision.

How ! to code

tonyschr — Wed, 05 Oct 2005 05:21:00 GMT

A little rant to prove I'm still alive. :-)

Here's a pattern I see every now and then that makes my brain explode. This is a simplification, but the two bools that are named exactly the same except the word "Dont" are real, as is the "partial assert" and not-completely-mutually-exclusive logic that follows. Can anybody explain why you would write code like this?

bool fDoFoo = SomeLogic();
bool fDontDoFoo = SomeOtherLogic();

assert(!(fDooFoo && fDontDoFoo));

if (fDoFoo)
{
    // Do something
}

if (!fDontDoFoo && !fDoFoo)
{
    // Do some other thing
}

XP SP2 fixes

tonyschr — Mon, 26 Jul 2004 05:10:00 GMT

One interesting change I discovered in XP SP2 was that ~~Subspace~~ Continuum -- the first and (by far) best massively multiplayer online game -- now runs on XP without entering an infinite loop trying to launch the process. This only repro'd under certain accounts, and I suspect it was a bug in their anti-hacking/cheating code, but SP2 seems to fix the problem.

Well, what are you waiting for? It's free! Start playing today! I can sometimes be found as “IUnknown*” in Alpha West (I'm a perpetual newbie). Mention that you saw my blog and I won't kill you. :-)

[Edit: Speaking of great games, here's a remake of Lemmings in DHTML! Very cool, I wonder how long this link will last. What ever happened to Psygnosis? Their games for the Amiga were excellent...]

Breaking-in electronics

tonyschr — Tue, 15 Jun 2004 05:51:00 GMT

For best performance, you should make sure to break in your cables. Otherwise, you may be getting substandard audio performance and transfer rates - I hear that breaking in your modem cable will let you get 64kbps out of a standard 56k modem!.

;-)

Expression 3: Vector drawing application available for download

tonyschr — Mon, 07 Jun 2004 22:09:00 GMT

As others have pointed out, Microsoft has made available a free download of Expression 3, apparently acquired from Creature House. My first impression, having only played with it during breakfast and lunch, is that it's a very cool app. It has a standard, user-friendly palette-based UI with a few interesting quirks -- a good antidote to applications such as Digital Image Pro that favor a more “Inductive UI” style approach. ;-)

From reading the comments on Tim's blog I now notice that a note on the download web page implies it's for existing customers. When you install, the EULA doesn't say anything extraordinary, although it does call it a “Preview”, and there's a non-intrusive “Preview” watermark in the MDI client area. Until we hear more official communication, draw your own conclusions I suppose. (Or paint them using MS Paint, but that would just be a bad pun.)

On a side note, I'm a bit puzzled by how schizophrenic Microsoft has been in the graphics space. We built and discontinued Image Composer, Photo Draw, and Photo Draw 2000, and created Digital Image Pro, Picture It, and various image manipulation and drawing features in apps like Office and Visual Studio. We also bought Visio, and bought and sold SoftImage. Of course, there's MS Paint. And rumors about Sparkle. Am I missing any?

My MSN

tonyschr — Sun, 30 May 2004 01:28:00 GMT

I'm not sure when the changes happened, so this could be really old news, but I was pleasantly surprised when I visited http://my.msn.com today.

It's always been configurable, but now it's pretty slick. You can easily add and remove content modules that you're interested in (Hotmail inbox preview, news, sports, weather, entertainment, stocks, etc.) and completely configure how and where they're shown. Configuration is done through live drag and drop... you can even resize the columns by dragging splitters that show up when you hover over a column border! The UI is dense in terms of information, but doesn't feel cluttered like the main MSN home page.

A Good MP3 Player

tonyschr — Fri, 14 May 2004 02:11:00 GMT

Check out these features:

Supports MP3 and WMA (and mounts as a hard drive)
4 GB storage
10+ hr removable lithium-ion battery
Size is 3" x 2.5" x 0.4" for the one standing up, 2.4" x 3.1" x 0.4" for the one laying down. Around the size of the iPod mini, but smaller in some dimensions.
USB 2.0 or Firewire, and recharges over the connection
RIM-style navigation, including side scrollwheel and back button
AM/FM radio, including "Personal Audio Recorder" features such as recording at scheduled times, pausing live radio, and actively buffering the last 30 minutes in RAM

There's only one problem: it doesn't exist.

I've been looking for an MP3 player with, at minimum, 4 GB, WMA support, and a built-in radio (not on a "remote"). Ideally it would be relatively small with a big display and navigation that doesn't require a clumsy protruding joystick-like apparatus. Any suggestions?

My failure to find a good player did give me an excuse to do some 3D modeling and rendering, though. :-) The above image illustrates what I want hardware-wise (within the constraints of current, inexpensive technology) and is also my first attempt to use radiosity and HDRI in Lightwave. There are no lights in the scene, only the High Dynamic Range Image for the environment, and a gray plane for the ground. This approach tends to produce more realistic images, at the expense of rendering time: the 800x600 version of this image took over 48 hours to render on a 2.4 GHz P4. Of course, there are a variety of techniques you can use to significantly reduce rendering time (using multiple passes, "baking" radiosity info onto the surface, interpolated mode, etc.), but so far all of the things I've tried degraded the quality too much for a still image like this one (reflection, etc.).

Getting the flat menus back in Windows XP

tonyschr — Mon, 10 May 2004 23:39:00 GMT

I'm not sure if anybody else has this problem, but after I have used XP for a while the menus seem to revert to an ugly 3D look instead of having the clean, flat border. No amount of tweaking seems to get back the flat menus except going back to the original XP theme and re-customizing everything.

After turning up empty handed on Google and elsewhere I diff'd the registry against a machine I hadn't contaminated yet. Here's the registry key that seems to cause it:

3D menu look

[HKEY_CURRENT_USER\Control Panel\Desktop]
"UserPreferencesMask"=hex:90,32,05,80

Flat menu look

[HKEY_CURRENT_USER\Control Panel\Desktop]
"UserPreferencesMask"=hex:90,32,07,80

You'll need to log out and log back in again to make it take effect. As always, edit the registry at your own risk.

High DPI in IE: Tip & Mystery Solved

tonyschr — Wed, 05 May 2004 07:53:00 GMT

On his blog (and in a comment on my 120 DPI post) Omar points out a super-secret registry tweak make IE do extra scaling in high DPI mode. IE already adjusts for well-written web pages, but if you're using high DPI and still feeling cramped on some sites, you might want to give it a shot.

I don't like it because it has a tendency to distort graphics, and it makes some fonts too big for my displays, but it's good to know about. I mentioned an alternative in my own comments a few weeks ago, but I suspect not many people saw it. For the occasional web sites that hard code small font sizes, here's a very simple “per-page zoom” workaround:

1) Create a local file (i.e. c:\web\zoom200.htm) that has the following script:

<script language="JavaScript">
external.menuArguments.document.body.style.zoom="200%";
</script>

2) Add it to the right-click menu in IE, by adding a registry key:

Key: "HKCU\SOFTWARE\Microsoft\Internet Explorer\MenuExt\Zoom 200%"
Value (Default): "c:\web\zoom200.htm"

Adjust the zoom percentage and file locations as needed and then restart IE. Now when you right click on a page the menu should have a new option to “Zoom 200%”. Clicking on that will zoom the entire page, including graphics and (most) controls. A 125% or 150% zoom is probably more reasonable for normal reading; I've created several zoom levels in this way. Unfortunately zoom has a few issues with font kerning/spacing, selection, controls, and an overall lack of polish, which is why you don’t see this exposed directly in the browser yet.

Fonts on XP

tonyschr — Wed, 28 Apr 2004 09:04:00 GMT

Scoble and Dudley are having a debate about fonts and I can't help but think the little screenshot isn't enough to go on. For one, it's clear that Japanese fonts are not rendered using ClearType, so that's a topic for a different day. Right now I want to focus on regular Latin fonts.

I've put up a test page along with a screenshot that shows what everyday fonts look like on my Windows XP machine (with ClearType, tuned to my eyes on a Dell 2000FP, and 120 DPI fonts). I'm interested in seeing comparisons rendered on OS X, Linux, Windows with different settings, etc. Feel free to swap out fonts with ones you think look better; overall quality is what matters, not font-for-font rendering comparisons.

Note: When viewing the screenshot, make sure you have image scaling disabled. Also, if you post your own, please use PNG.