21–30 of 82 posts
Earlier quoted context omitted.
True. A trial version would be very nice. One thing I would like to see is being able to export these vector graphics to other formats.
You may want to check out Opacity ( http://likethought.com/opacity/ ) which can export to ObjC, HTML5 Canvas, SVG and PNG/Jpeg etc.
but lets hope this one gets updated often.
Windows MetaFile contain(ed) serialized GDI graphic calls to generate the picture in a resolution independent way, while still working as a vector file format that other application could parse.
Generating static ObjC seems like a dumb idea except in very specific cases.
Sometimes ideas are just floating around, aren't they? I was thinking of very similar things lately as well. Obviously this application must be under development for quite a while already. One thing that I'm not totally sold on it that fact that it generates code though. It is not going to be the running application which you interactively tweak. Because that is what Bret was showing in his talk. And that is also wha…
I think Opacity [1] was the first program with this feature (added in 2009 [2]).
I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…
And I don't get why Apple bothers with CgBi PNGs, since endian swap on ARM is a single cycle instruction, and it's probably free anyway while moving the bitmap to the GPU memory.
Sometimes ideas are just floating around, aren't they? I was thinking of very similar things lately as well. Obviously this application must be under development for quite a while already. One thing that I'm not totally sold on it that fact that it generates code though. It is not going to be the running application which you interactively tweak. Because that is what Bret was showing in his talk. And that is also wha…
Haven't quite got it ready for launch yet, but rest assured the idea is not new. There have been Inkscape exporter tools for this sort of thing for years, you just have to know where to look (inkexport, &etc.)
PaintCode sure is pretty, though.
I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…
iOS devices can render Infinity Blade smoothly. I don't think few shapes (probably automatically cached as a bitmap) are going to be an issue. And I don't get why Apple bothers with CgBi PNGs, since endian swap on ARM is a single cycle instruction, and it's probably free anyway while moving the bitmap to the GPU memory.
Earlier quoted context omitted.
True. A trial version would be very nice. One thing I would like to see is being able to export these vector graphics to other formats.
You may want to check out Opacity ( http://likethought.com/opacity/ ) which can export to ObjC, HTML5 Canvas, SVG and PNG/Jpeg etc.
I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…
iOS devices can render Infinity Blade smoothly. I don't think few shapes (probably automatically cached as a bitmap) are going to be an issue. And I don't get why Apple bothers with CgBi PNGs, since endian swap on ARM is a single cycle instruction, and it's probably free anyway while moving the bitmap to the GPU memory.
The SoCs in iOS devices are shared-memory systems, so system memory is GPU memory.[1] But you're right, the endian swap could easily be done in the PNG decoder.
[1] I have to admit I'm not sure it's implemented as zero-copy through to userspace, though. The normal, 20-year-old GL texture APIs can certainly only be implemented via copying, and I'm not sure if OpenGL ES has anything like mappable texture pixel buffers. It would make a lot of sense though, considering how memory-starved embedded systems are.
I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…
It depends a lot on the representation. Bitmap will not get a lot better than what we've got at the moment with JPeg or Gif. Vector representations can vary wildly in compactness and rendering speed. Eg. SVG bad, CSS gradients good. SVG bad, EPS/PDF good.
Obviously drawing from CPU can be much quicker than reading from disk. And if you draw into the GPU buffer first you get all of the advantages of GPU acceleration later.
And it can be much more bandwidth efficient.
Take streaming a bitmap over http. You have to take the penalty of the PNG header, the penalty of assembling a data:url and a 33% fixed penalty for Base64 encoding the binary bits.
So to stream a 1x256px gradient sprite there is a shedload of wasted bits.
If you're in vector land you can just send the gradient endpoints.
If you're not in WebKit land or with pre-sent vector algorithms (rare) you also have to stream the vector drawing code. In that case you can ammortize the cost of the drawing code with a simpler/smaller wire representation.