Pictomaphone has been Submitted

Pictomaphone is my very first Windows Phone 7 application – and I just submitted it to Microsoft this morning for Certification. Hopefully in a day or so it will be available to the world.

So, what is it and why the silly name? 

Pictomaphone is a basic image editing application for the phone. It lets you open an image from your device (or take one using the built in Camera app) and make changes to it.

The silly name comes from the fact that it is very difficult to come up with a name for a photo app, that has photo or picture as part of the name, that isn’t already being used by someone else. I literally went through 100′s of name ideas. Last night, the day before I submitted it, I finally landed on Pictomaphone… a play on Picture and Homer Simpson’s “Saxomaphone.” I liked the phone part since it is a phone app. If I decide to port it to Windows 8, I may keep the same name, though, because Pictomapad doesn’t have the same ring to it.

So, what are the features?

Well, the first feature is that it is FREE. I made it free, even though it took a lot of my time, because it didn’t have all the features I wanted and some things weren’t quite as polished as I would have liked. That being said, there will be updates… and at some point it won’t be free anymore.

It has a File/Edit menu with “Take a Photo”, “Open a Photo”, “Save your Photo” and “Rotate.”

Other than that, it has the usual list of Photo Adjustments:

  • Brightness / Contrast
  • Channel Mixer
  • Hue / Saturation
  • Colorize
  • Grayscale
  • Sepia
  • Colored Filter
  • Negative

It also has some Effects:

  • Blur (which is really slow)
  • Dreamy Glow (which is also slow)
  • Gritty Contrast (which is waaay better than normal constrast, IMHO)
  • Vignette (for making it look like it came from an even crappier camera)

But, it also has a full-screen Preview mode – that lets you pinch to zoom and pan around the image. This is by far my favorite feature that was missing from other Photo apps.

In the future, I plan to add:

  • Crop – I had to cut it from Version 1, but it is a must-have for any decent Photo Editing app.
  • Levels – just like in Photoshop, cause it is a better way to fix brightness/contrast problems.
  • Posturize and Solarize – even though I think both look crappy, I can add them, so why not.
  • Borders – cause they can be nice
  • Filters – a little like Instagram, because people seem to enjoy them.
  • Sharing – even though it is built into the phone, it would be nice to have in app.

WP7 Silverlight Low Level Performance

Okay, while trying to figure out why some of my pure math code was running sluggish, I decided to see how the low level math ran on the phone. Stuff like, should I use an int, float or double? How much faster is a bit shift than multiplication?

I wrote a quick Silverlight page that runs a test method (on the UI thread) and does a whole bunch of math in loops. I also used the Compiler Services namespace to hide the method from the debugger and turn off optimizations.

This is probably the least scientific test of performance, but it’ll do in a pinch. I’ve used integer addition on the emulator as the base (int add = 1) and calculated everything from there. So, it is in units of integer additions on the emulator running on my machine.

Note: there was a play of about +- 0.2 when running multiple times. It was even higher ( +- 0.5) for division.

Here are the results:

Operation Emulator HTC HD7
int + 1 1.6
int >> 1 1.6
int * 1.1 1.8
int / 4.1 13
int % 3.7 13
int -> float 2.8 3.9
float <- int 2.5 1.9
float + 2.6 2
float * 2.9 2
float / 3.9 6.4
int -> double 1.7 2.7
double -> int 3.3 1.9
float -> double 2.2 1.9
double -> float 3.3 2.4
double + 3.1 1.9
double * 3.5 1.9
double / 4.4 6.5

There you have it. In general, don’t divide (or modulus)! If you need to divide, use floats or doubles.

Integers barely outperform floats and doubles, it is close enough that I’d call them equal.

Casting isn’t nearly as bad as I thought it would be – with casting to an Integer being practically zero extra cost!

I wouldn’t plan your whole performance strategy around these numbers… try it on your own! Let me know what you get.

WP7 Silverlight: Performance of Method Calls

In working on my little photo editing app for WP7 I had a function that was running crazy slow.

The method in question had a loop that ran 480,000 times over the pixels in a test image. Inside this method I called out to a helper function to perform some math on the colors in the pixel.

The function ran way slower than similar methods that had all of their code inlined. This was especially noticeable on the phone itself. In the emulator, it was slow but bearable. On the phone, it was unusable for me. I know that method calls have some overhead, but this seemed a bit much.

I moved the entire loop into the helper function so there would be only one call. Things sped up by about 4x; Guess that’ll teach me. It works much better on the phone now. After some additional performance tuning of my math, it should be nice and snappy!

Lesson: Don’t make method calls during long running loops if you can avoid them. They are too slow.

WP7: Application Bar Click Event Problems

Working on my Windows Phone 7 application in Silverlight, I ran into a problem when the Click events on my Application Bar didn’t seem to fire.

Specifically, they don’t fire when calling out to one of the Chooser Tasks (photo in my case).

Apparently, there is a bug of some sort in the way controls are hooked up… when you return from a chooser, you are on a different thread than your normal UI thread. If you navigate to another page, then things get wacky and while the App Bar loads, it doesn’t hook up events.

The fix for this is in the Chooser Task completed event, use Dispatcher when making navigate calls…

Example (straight from my current source code):

    void photoChooserTask_Completed(object sender, PhotoResult e)
        if (e.TaskResult == TaskResult.OK)
            BitmapImage bitmap = new BitmapImage();
            WriteableBitmap picLibraryImage = new WriteableBitmap(bitmap);
            (Application.Current as App).selectedPhoto = picLibraryImage;
            Dispatcher.BeginInvoke(() =>
                    this.NavigationService.Navigate(new Uri("/PhotoEditPortrait.xaml", UriKind.Relative));

And there you have it. It works perfectly for me. It would be nice if the framework did this automatically, since the App Bar isn’t really part of your UI, but oh well. This is how it is right now. If anyone knows of a better way to fix this

Developing for Windows Phone 7

This weekend I hacked together a WP7 app using Silverlight. I’ve done Silverlight programming for the web a few times, so it wasn’t too big of a deal at all. Other than a few phone specific details it was largely the same.

For people who haven’t used Silverlight or WPF to build an app before, it is a break from regular .NET UI design, but not too different from web development.

In fact, developing for the phone reminded me a lot of web development. I think people who are expecting things to work like desktop apps are going to be sorely disappointed, but if you get out of that mindset, it isn’t that bad.

As a developer, not having complete control over everything on the system can be annoying. But, as a user of the phone, I think it works out great. I don’t want apps taking over my phone! I want things to be snappy and use as little battery as possible, which seems to be what Microsoft was aiming for.

My roommate has an Android phone that only keeps a charge for about 5 hours. It is partially his fault for keeping a gajillion apps running at all times, but he isn’t computer savvy. He shouldn’t be expected to know how to manage all of that crap, it is a phone! With a Windows Phone 7 Phone (.. for windows phone phones) he wouldn’t run into that problem.

Multi-tasking can be nice, but I haven’t really had a problem not having it on my phone – as long as the apps handle navigation and tombstoning properly, things are pretty seamless.