Last progress update; http://crtags.blogspot.com/2013/02/dtracearm_16.html
190 karma · joined February 4, 2011
I have a strong suspicion that CGAffineTransform and its associated methods are calculated through the ARM NEON co-processor. I don't see anything in the documentation you provided that mentions the GPU.
It _could_ be done in a vertex shader on the GPU, but looking at the API, the use of Rotation, Scale and Translation methods seems more consistent with it being done on the CPU or the CPU's floating point co-processor. Otherwise, there would be something equivalent to glBegin() or glEnd() to prep calls to update the uniforms for the shaders and render to the frame and render buffers, much like CA's transaction based API for animations - the block based API is similar, too.[1] Frankly, switching to a shader just to do rotation/scaling/translation is a bit much, and better left to the CPU in most cases.
Andy Matsuchak of Apple claims that "When you implement drawRect or draw with CoreGraphics, you're using the CPU to draw, and that drawing will happen synchronously within your application. You're just calling some function which writes bits in a bitmap buffer, basically."[2]
That is rendering. Unless you're confusing rendering with compositing layers, the act of blending several CALayers/UIViews together.
The compositing bit is completely dependent on how you opted to draw your layers; some can be composited on the CPU, others on the GPU. I've listed all the ways that a layer can be composited on the CPU, it's just something to watch out for.
[1] - I'll grant you that CA has an implicit animation API, but CA also has a much more elaborate system of keeping current state and projected state in place. CA has layer trees for each to avoid having to block the CPU and wait on the asynchronous GPU for results, which CG doesn't.
[2] - http://robots.thoughtbot.com/post/36591648724/designing-for-...
QuartzGL runs all Core Graphics on the GPU[1]. It's only available on OS X.
If you can show me evidence that some API on iOS runs Core Graphics on the GPU, I'd be happy to know. I do a fair amount of work running Core Animation, CG and OpenGL at the same time, so it would be a big help.
[1] - http://www.cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing...
Since you're only using Core Graphics, this is acceptable. Core Graphics only has a CPU implementation on iOS. Core Animation has a CPU implementation that only gets activated under certain conditions; otherwise, it renders through the GPU by default.
If you're planning on using CA...
- outside of -drawRect:,
- with no shadows or masks (transparent gradients, for instance,)
- without text (CATextLayer, UILabels, Core Text, UIFont,)
- with -shouldRasterize: assigned to NO (the default,)
- without overriding -drawInContext: (which draws a CALayer's content to a CGContext,)
- with any OpenGL code at all,
...you're going to quickly end up in the land of seconds per frame instead of frames per second.
I went to a few private schools (K-8, K-12) staffed with teachers like that, when I was younger.
I think you will be very surprised as to how much people don't know. The regurgitation of information isn't a byproduct of laziness; it's a direct result of two things.
1. People don't like to read.
2. There is far, far too much noise on the web, as it is.
It may have already been said, but I'll guarantee you that only a small minority ever read it.
You could talk about what it is that you know. What it is you hope to know. Not every developer takes the same road. If your intent is to eventually position yourself as a domain expert, the rest should write itself.
Don't get too hung up on being an original provider of content. Few people are. Rather, think more about presentation. Anecdotes, history, even trying to spin something into a more modern context. They all matter.
Keep writing. Keep writing often. It's the only way to get better.
I've worked on projects at past jobs where the designs demanded that we duplicate the look and feel of certain iOS system APIs and programs to a T. Apple passed those through approval without making a sound about those bits.
On the other hand, Tapbots has had an app rejected in the past for using a clock icon that looked a little like Apple's[1], back in 2009. And that wasn't an exact copy.
We're not going to get an official statement from Apple on this, so the best I can suggest is to tread with caution. Better to be inspired by than to flat out copy.
[1] - http://tapbots.com/blog/app-store/a-well-timed-letter-of-rej...
The best thing I can say in The Daily's favor is that the app took advantage of the native frameworks for kerning and text layout, even if the hyphenation was screwed up.
For an app like The Daily to take better advantage of being a native app, there'd have be better tools available to content creators so that they can actually use those features. Camera input. Keyframe animations. Multitrack audio. Even, dare I say it, 3D content.
No Postscript, no PDF.
You can see this for yourself if you let Charles or any kind of wire sniffer observe the network traffic while The Daily loads a new issue.
- iPhone + Android phone sub
- iPad AND iPhone + Android phone sub
Android phone is equivalent to Kindle Fire. I have no idea why the Kindle was promoted over the Android phone, but it wasn't originally conceived as an exclusive.
Even to this day, I have no idea how the Android tablet subscriptions were handled. It was a Verizon exclusive, it was preloaded for exactly one tablet and it couldn't be uninstalled. I don't even know how many tablets were sold like this, but I don't believe it was many.
The Daily for Android tablet did an impressive job of replicating some parts of UIKit for Android. Shame nobody saw it.
The Daily was an effort to compete with the likes of TMZ and USA Today. Light on reading, heavy on "entertainment." And kept snugly within the bounds of a paywall.
Marco's magazine might work for something like IEEE or ACM, but I can't imagine News Corporation buying into it. They really, really did not want to let go of the pretty pictures and panoramas. :)
Midar doesn't slack around when it comes to portability. :)
GLSL 3.3 was present but hilariously broken in Lion, if you explicitly requested it in your shaders.
Hopefully things will improve for Mac OS X 10.9.
Still receiving frequent updates and new features. It's been exciting to see it come together.
My biggest caveat has been the OpenGL ES support on Android. It only builds properly on Linux, and it doesn't support performance profiling the last time I checked. You're better off using vendor specific tools like Nvidia's PerfHud ES for Tegra devices and PVRTrace for PowerVR devices for that sort of work.
There's also no support for OpenGL ES on iOS devices. Fortunately, Apple's OpenGL ES profiling tools for Xcode are (surprisingly) quite solid, and much less of a pain in the butt to set up than any Android OpenGL ES solution. As long as you're content with there being only one game in that town.
EDIT: And for taming GL Extension Hell, GLEW is still the best; http://glew.sourceforge.net . If you see a tutorial that suggests anything else, it's wrong. :)
You can use Smalltalk-style messaging that C++ and C alone wouldn't give you. So you can query objects for methods, variables, and other things that they may or may not have without causing your entire app to crash.
You wouldn't have to wait at runtime for a VM to startup, since Objective-C has no VM. :)
Just a few things.
If all you're looking for is constructors and destructors, consider ObjFW. https://github.com/Midar/objfw/
ObjFW is much more lightweight, although it does have its own set of conventions. Fortunately, +alloc, -init, +new and -dealloc are all present and accounted for.
http://www.google-melange.com/gsoc/project/google/gsoc2012/i...
"This proposal covers implementing a flexible animation API compatible with a certain popular existing desktop and mobile platform, as well as adding APIs compatible with a popular mobile platform. This will allow extremely user-friendly interfaces, as well as allow development or porting of applications that use CoreAnimation or UIKit API on platforms that don't yet support it."