

PaintCode - Vector Based Obj-C Graphics Code Generator - J3L2404
http://paintcodeapp.com/

======
tptacek
I'm waiting for someone to tell me what's horribly wrong with this before I
click the "Buy" button, but it's taking effort to resist the urge. This looks
extremely excellent.

~~~
thought_alarm
Core Graphics drawing is actually quite slow. On the Retina iPad, drawing is 4
times as slow and uses 4 times as much memory as the 1st gen iPad, and all the
CPU cores in the world are not going to help you.

Having recently ripped out most of my -drawRect: methods, replacing them with
custom rendered UIImages, I can attest to the significant performance gains
that UIImage gives you. On the Retina iPad, I think it's pretty much
mandatory.

With that in mind, I think most people are better off using a tool like this
to produce PDF data rather than raw CG calls, and use generic code to render
that PDF data to a UIImage. PDF data produced by Quartz is going to render
exactly the same as raw CG calls.

It makes for easier project management, and much better performance.

Of course, if you don't need resolution independent graphics, just use png.

~~~
Zev
Its not that Core Graphics is slow, just that CG doesn't guarantee that
drawing will take place on the GPU. It turns out that CG typically prefers the
CPU for its its drawing. In comparison, when you load images into a
UIImageView, you know that the drawing will be done on the GPU, instead.

Quick question: How does UIImage's -drawInRect: and -drawAtPoint: differ?[1]

 _With that in mind, I think most people are better off using a tool like this
to produce PDF data rather than raw CG calls, and use generic code to render
that PDF data to a UIImage_

The CGPDFPage* functions that Apple provides are document-oriented (remember:
the D in PDF stands for "document"), and don't necessarily work well in all
cases, either. A compromise could be to render your CG calls into a context
that is then turned into a UIImage that gets cached and stuck into a
UIImageView for display. This way, you can do your drawing in CG*, get GPU-
backed rendering, and don't have to deal with clumsy PDFs to get images.

So, my advice? Click the "buy" button. Drawing in code is just another tool to
have. No reason to avoid doing so, if the situation calls for it -- and the
trick to any tool is knowing when to use it.

1\. If you guessed that -drawInRect is CPU-backed and drawAtPoint: is GPU-
backed, pat yourself on the back. Simply having your resources in a UIImage
isn't enough to guarantee GPU-backed drawing. And drawing on the GPU isn't
enough to guarantee that it will be fast.

~~~
ryanpetrich
drawAtPoint: and drawInRect: both call through to drawInRect:blendMode:alpha:
which calls through to CGContextDrawImage. CGContextDrawImage has some
optimizations to handle unscaled blends and further optimizations for unscaled
blits, but it doesn't use the GPU on iOS. Even if it did, it would be using
the GPU to draw into a temporary buffer that would have to be drawn again when
the QuartzCore scene is rendered.

------
0x09
Previous discussion: <http://news.ycombinator.com/item?id=3707421>

------
frankus
I'm interested in pretty much the exact opposite of this product.

I've worked on a few apps where I need to pre-render some high-quality images
and include them in the app bundle. In some cases they are relatively
difficult to hand-draw in an image editor (at least the sort of image editors
I can afford) and I've had to write a Mac app to draw the image. Basically the
sort of thing that a CAD program would be good at.

So I'd love to have something that I can script in a relatively high-level
language that renders really sharp antialiased graphics at 2x resolution with
control over things like end caps.

------
evincarofautumn
IANAL, but does this violate the part of Apple’s iPhone Developer License
Agreement that says “applications must be originally written in Objective-C,
C, C++, or JavaScript”? The code is “written” in Objective-C, but it was
“originally” not code at all.

~~~
samnm
I don't think that's part of the developer license agreement any more.
Considering how successful Unity, Corona and other non-obj-c development tools
have been I'd be surprised if it was.

~~~
evincarofautumn
Don’t know. The last I heard of it was mid-2010, and there doesn’t seem to be
new information saying it’s changed. Apple seems bent on killing Flash, and
that wording was a perfect way to deal with CS5. Unity, on the other hand, has
a good relationship with Apple, so there’s no reason for Apple to invoke Dread
Section 3.3.1 against them.

~~~
gte910h
That is not part of the license anymore.

~~~
evincarofautumn
Thanks for clearing that up. I just didn’t know and couldn’t readily find it.

------
illicium
Hardcoding... graphics? Why?

~~~
gte910h
People are currently using PNGs

So you're hardcoding either way.

Additionally, paintcode has the flexibility of making say, a button that
shrinks/grows based on the shape of another view, say, as is caused when you
rotate an ipad, etc.

I've been very happy with the product so far.

~~~
shock-value
This product just outputs Obj-C, which must be baked into your source code,
right? That's what I think of as hardcoding. I wouldn't call loaded PNG's from
outside of the binary "hardcoded".

I can certainly see where having easy programmatic access to the primitives
that make up a vector drawing would be useful though.

~~~
gte910h
It outputs code that you can customize dynamically though...unlike pngs

