Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PaintCode - Vector Based Obj-C Graphics Code Generator

paintcodeapp.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#11

Post by shock-value »

gte910h wrote: post #5
illicium wrote: post #2

Hardcoding... graphics? Why?

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.

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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#12

Post by J3L2404 »

tptacek wrote: post #10
J3L2404 wrote: post #7

Earlier quoted context omitted.

There is a trial version so try away.

The money is irrelevant. $70 is chump change for any application I care about enough to do custom drawing in. But if there's something unworkable about the approach, I sure wouldn't want to waste my time. (I have a couple Mac Cocoa apps I'm working on that I kinda sidelined because UI controls were painful).

I see. Well $70 isn't irrelevant for everyone so I am glad they have the free trial. Good luck on your apps!

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#13

Post by thought_alarm »

tptacek wrote: post #6

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.

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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#14

Post by 286c8cb04bda »

tptacek wrote: post #6

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.

I've used it, and had no problems at all. It's missing a few features before I can whole-heartedly recommended it over Opacity[1], which is what I use for the same purpose right now. Right now I'd need to make separate on/off state, for example, for each button. Opacity's factories & variables make that much easier.

That said, Opacity's development has slowed to a crawl. If the gentleperson(s) behind PaintCode keep it up, they will surely surpass it very soon.

[1]: http://likethought.com/opacity/

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#15

Post by Zev »

thought_alarm wrote: post #13
tptacek wrote: post #6

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.

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 p…

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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#16

Post by 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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#17

Post by samnm »

evincarofautumn wrote: post #16

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.

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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#19

Post by evincarofautumn »

samnm wrote: post #17
evincarofautumn wrote: post #16

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.

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.

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.

Re: PaintCode - Vector Based Obj-C Graphics Code Generator

#20

Post by acidblue »

evincarofautumn wrote: post #16

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.

Seriously? That's like saying if you thought of the code, wrote it down on paper or started off as UML diagram that it would be invalid. I hope you were kidding.
Post reply on HN