Draw NSImage for both retina and non-retina?

There's a new method that creates an NSImage by passing in a block of code that is executed to do the drawing. That block will be executed every time the image needs a different resolution (for example, if you have a Retina MBP with an external monitor, and move a window between monitors).

 

Your battery indicator isn't that complicated. All of it can be drawn in code with some little known tricks. Of course, the issue is learning how to.

I'm no graphics wizard, but all of the added runtime graphics in my iOS app are created at runtime. The app icon it self is created via a Mac app I wrote specifically for that purpose. I did it this way so I could learn about the graphics frame works. This knowledge came in handy just this week for for an iPad app where we have a bluetooth barcode scanner connected and want to report the battery level.

The obvious starting place is the Apple docs. A Google search of the following words returns some good links; Cocoa Drawing Guide Introduction

Cocoa Dev Central has a couple of intro articles that may be of interest to you; Introduction to Quartz, Intro to Quartz II.

The Advanced drawing using AppKit over at Cocoa With Love shows you how to draw something that looks very complicated.

I don't know about the OS X calls for retina displays, but I would think that when you start your app you could fetch the scaling you need and create an appropriate sized view. From then on the drawRect would always use that size.

A tip that was given to me about drawing dynamic graphics was to think in layers. Like you may do when using a graphics drawing program. When you do that, you figure out what has to be done in which order. That breaks down the work into logical groups that you can attack individually and before you know it, you have a nice image.

When I first wrote my graphics for CameraTime, I was thinking in the points system of an older lower resolution iPhone. I later discovered the scale function to get the scaling of the device and adapted my math to that value of either 1 or 2. The graphics now appear sharper on devices newer that an iPhone 3GS. To put that another way, the 3GS is the only low resolution device I currently support.

Sure, this may be technically beyond what you can do now, but you can easily gain the knowledge in a short time to duplicate or even expand on your icon.

 

I think it's new in Mountain Lion. Specifically for HiDPI support.

Your drawing commands would be identical for Retina and non retina, but when the NSImage is used on a retina display, the drawing commands will create an image in retina resolution.

developer.apple.com -> Mac Dev Center -> Featured Content / What's new in MacOS X -> MacOS X v10.8 Mountain Lion -> Block-Based Drawing for Offscreen Images

 

I've been using PaintCode.
http://www.paintcodeapp.com/

It seems to work well and is great for a novice like myself as I can see how different drawing commands are used. And also make a higher quality graphic much quicker than my current level of programming skill would normally let me. It also give immediate feedback as to what an image will look like and how changing the drawing parameters will change my image all without recompiling the program.

I also like how the drawing canvas can be toggled between normal and retina to show you how your image will look at the two different resolutions. It also can output normal and retina .png's.

Overall, I've found it to be well worth the money. I bought it through the App Store, but I think there is a demo version available on the website.

 

WWDC 2012 session 245 might help a bit with that new method. The piece of interest starts at 7:38. It looks interesting. It is also mentioned in session 204.

Personally, I think you should be looking at using NSView and drawRect:. That may be old school thinking. LOL. I'm thinking you want to draw a different image each time a level changes. Once you've written drawRect code, the action to redraw is as simple as calling setNeedsDisplay on the view. Perhaps you can combine the two ideas.

 

Don't use an NSImage. Instead, you'd get the CGContextRef of the NSView, and draw into that.

Or make an off-screen bit-map and gets its context, draw into that, then get that as an NSImage. Or use an off-screen CGLayer.

If you haven't read the Quartz 2D Programming Guide, you should. There's a whole section on getting a graphics context to draw into.

 

1. You don't need a retina display to test this. Use Quartz Debug to enable HiDPI modes on your display. Basically that changes for example a 1920 x 1080 monitor to a 960 x 540 Retina display with really huge pixels.

2. To support earlier OS versions I'd write something like (you'll need to fix it to make it compile)

Code:

^BOOL (NSRect destRect)myDrawingHandler = ^...;

NSImage* image;
if ([NSImage respondsToSelector:@selector (imageWithSize:flipped:drawingHandler:)]) {
   image = [NSImage imageWithSize:... flipped:... drawingHandler:myDrawingHandler];
} else {
    image = (old way to create an image);
   ... set up image for drawing
   myDrawingHandler (...);
}

So you _either_ get an image that redraws itself as needed, or on an older OS you draw it once. I'd assume that any Mac with retina display supports the new calls.

 

To get an NSImage from an NS view, it looks like you use dataWithEPSInsideRect: or dataWithPDFInsideRect: and work from that.

You've now specified something I didn't know; That the menu bar can only display NSImages. Given that tidbit of info, I suspect you don't want to bother with an NSView. Since it wouldn't be displayed, I don't think it would redraw automatically. I think as a first pass to this I'd just create a new NSImage each time I need one. One for the menu bar, and one each for the menu items. You could reuse the menu bar one for the low value on the menu items by drawing into another NSImage for the item.

I'm starting to come up with more questions. Both technical and implementation wise. Wish I had time to code this up. It would be a fun little learning exercise.

 

In terms of actually constructing the image, I'd suggest composing from a few separate images instead of trying to do it all in code. I think trying to create complex bezier paths in code will turn out to be more hassle than it's worth.

For your purpose, I think you need three images: the battery outline, the charge level indicator, and the plugged-in indicator. The graphics context will allow you to add clipped regions and specify composition options as you build up your image to create a number of different effects.

I've created a project that allows for arbitrary charge levels and sizes using those three image. It uses the block-based NSImage method to:

1. Draw the level of charge, clipped to the level remaining.
2. Optionally draw the plugged-in indicator.
3. Draw the battery outline.

I hope this points you in the right direction, but if you need additional help I'm happy to post the project.