4 ms·
Hardcoding... graphics? Why?
by illicium 15y ago
Hardcoding... graphics? Why?
- J3L2404 15y agoResolution independence.
- DHowett 15y agoIf you boil down a UI element's description to a set of lines, colours and gradients, you can easily apply that to other elements at all scale factors, without having to ship piles of images (possibly in four different sizes, if you have iPad-specific assets) and deal with the horrible "stretchable images" system. That aside, the ease of prototyping makes development that much faster.
- ryanpetrich 15y agoStretchable images are quite elegant: they are relatively easy to use, use less memory and memory bandwidth, perform all drawing on the GPU when paired with UIImageView, animate size changes effortlessly and automatically share their buffer between all image views that use a single resource. You can certainly add all of this to elements that are drawn "in code", but it's considerably more work.
- gte910h 15y agoPeople 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 15y agoThis 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 15y agoIt outputs code that you can customize dynamically though...unlike pngs