0

I'm in the concept phase of a Mac application that should let the user easily select and layout images for printing. It's a document-based app and a document can have multiple pages with lots of pictures in different sizes and rotations on it. The UI would kind of be like the UI of Pages.app.

Those pictures can possibly be large hi-res images. The user should also be able to print them in the best quality that the images offer.

I have re-watched some WWDC sessions about Quartz, 2D drawing optimization and NSView.

I know that there are a few different ways of accomplishing what I want to do, namely:

  1. Use a custom view for a "page" and draw the images in drawRect: with Core Graphics/Quartz. Use CG transforms to rotate and scale images.

  2. Also use a custom view for a "page", but use NSImageView-subviews to display the images. Use Core Animation and layer transforms to scale/rotate images.

What is the best practice for this? Drawing with Core Graphics or using NSViews? Why?

Thank you so much!

  • Johannes
Johannes Fahrenkrug
  • 42,912
  • 19
  • 126
  • 165
  • This might be relevant, because the siblings should be able to overlap: http://stackoverflow.com/questions/466297/is-there-a-proper-way-to-handle-overlapping-nsview-siblings So it seems as if NSView is out of the picture. – Johannes Fahrenkrug May 21 '12 at 17:28
  • This is also relevant (displaying NSImages in CALayers): http://stackoverflow.com/questions/4950892/display-nsimage-on-a-calayer – Johannes Fahrenkrug May 21 '12 at 17:40

3 Answers3

2

Depends on how interactive these pages should be. If there is a lot of mouse interaction, e.g. dragging, selecting etc. I'd go with views. If you want fluid animations I'd even use plain CALayers with their content set to one image. This would also let you zPosition the images in case they overlap. A view based solution makes z-ordering hard. The drawRect method should be fastest but you have hard times integrating user interaction and you must z-order manually.

Sebastian Husche
  • 46
  • 2
2

This is a reply I got from opening one of my two Apple Technical Support Incidents:

Hi Johannes,

Thanks for contacting Apple DTS regarding your question about printing and the different ways to construct your applications general UI (with views).

There is a trend toward using layer-backed views in OS X (utilizing Core Animation layers) which is motivated by the ability to easily animate your application's user interface, with little work, when needed. However in terms of printing, you would be better off to implement drawRect for custom views so that the view contents can be drawn at "full resolution" when rendered into the context for printing.

If instead you use layer backed views at as those layers to "renderInContext" the layer contents would be used to render, which commonly will not be set to the full resolution of your source documents/images. This is because layer backed views take additional memory to store those bitmaps (cached layer contents), and because of that, they are recommended to be sized appropriately for the screen (which may not necessarily be sized appropriately for the printed page).

Does this help guide your application architecture? Please let me know.

So basically this means that using layer-backed views might result in sub-optimal printing quality. I've replied with some follow-up questions ("How setting wantsLayer = NO on the rootView right before printing help?") and will post the answers as soon as I get them.

Johannes Fahrenkrug
  • 42,912
  • 19
  • 126
  • 165
1

All three approaches should work. Since you should be using scaled-down representations of large images anyway, I don't think there will be much difference. Do what you feel most comfortable doing.

My guess is just using layer-backed NSViews (one par draggable image) will probably work best for starters. If you find performance lacking, you can always micro-optimize. Note that you may have to make your views a tad larger than the images so you can draw the selection handles outside them.

This is all assuming that you will never want to do a more complex drawing.

uliwitness
  • 8,532
  • 36
  • 58
  • Thank you very much for your input! No complex drawing will be required: The user should drag, scale and rotate images and possibly add text-objects later on. – Johannes Fahrenkrug May 21 '12 at 15:10