On iOS, I was able to create 3 CGImage objects, and use a CADisplayLink at 60fps to do
self.view.layer.contents = (__bridge id) imageArray[counter++ % 3];
inside the ViewController, and each time, an image is set to the view's CALayer contents, which is a bitmap.
And this all by itself, can alter what the screen shows. The screen will just loop through these 3 images, at 60fps. There is no UIView's drawRect, no CALayer's display, drawInContext, or CALayer's delegate's drawLayerInContext. All it does is to change the CALayer's contents.
I also tried adding a smaller size sublayer to self.view.layer, and set that sublayer's contents instead. And that sublayer will cycle through those 3 images.
So this is very similar to back in the old days even on Apple ][ or even in King's Quest III era, which are DOS video games, where there is 1 bitmap, and the screen just constantly shows what the bitmap is.
Except this time, it is not 1 bitmap, but a tree or a linked list of bitmaps, and the graphics card constantly use the Painter's Model to paint those bitmaps (with position and opacity), onto the main screen. So it seems that drawRect, CALayer, everything, were all designed to achieve this final purpose.
Is that how it works? Does the graphics card take an ordered list of bitmaps or a tree of bitmaps? (and then constantly show them. To simplify, we don't consider the Implicit animation in the CA framework) What is actually happening down in the graphics card handling layer? (and actually, is this method almost the same on iOS, Mac OS X, and on the PCs?)
(this question aims to understand how our graphics programming actually get rendered in modern graphics cards, since for example, if we need to understand UIView and how CALayer works, or even use CALayer's bitmap directly, we do need to understand the graphics architecture.)
Modern display libraries (such as Quartz used in iOS and Mac OS) use hardware accelerated compositing. The workings is very similar to how computer graphics libraries such as OpenGL work. In essence, each CALayer is kept in as a separate surface that is buffered and rendered by the video hardware much like a texture in a 3D game. This is exceptionally well implemented in iOS and this is why the iPhone is so well-known for having a smooth UI.
In the "old days" (i.e. Windows 9x, Mac OS Classic, etc), the screen was essentially one big framebuffer, and everything that was exposed by e.g. moving a window had to be redrawn manually by each application. The redrawing was mostly done by the CPU, which put an upper limit on animation performance. Animation were usually very "flickery" due to the redrawing involved. This technique was mostly suited for desktop applications without too much animation. Notably, Android uses (or at least used to use) this technique, which is a big problem when porting iOS applications over to Android.
Games of the old days days (e.g. DOS, arcade machines, etc, also used a lot on Mac OS classic), something called sprite animation was used to improve performance and reduce flickering by keeping the moving images in offscreen buffers that were rendered by the hardware and synchronized with the monitor's vblank, which meant that animations were smooth even on very low-end systems. However, the size of these images were very limited and the screen resolutions were low, only about 10-15% of the pixels of even an iPhone screen of today.
You've got a reasonable intuition here, but there are still several steps between contents and the display. First off, contents doesn't have to be a CGImage. It is often a private class called CABackingStorage which is not quite the same thing. In many cases there are hardware optimizations going on to bypass rendering the image into main memory and then copying it to video memory. And since the contents of various layers are all composited together, you're still a ways from the "real" display memory. Not to mention that modifications to contents just directly impacts the model layer, not the presentation or render layers. Plus there are CGLayer objects that can store their image directly in video memory. There's a lot of different stuff going on.
So the answer is, no, the video "card" (chip; it's the PowerVR BTW) does not take an ordered bunch of layers. It takes lower-level data in ways that are not well documented. Some things (particularly parts of Core Animation, and perhaps CGLayer) appear to be wrappers around OpenGL textures, but others are probably Core Graphics directly accessing the hardware itself. Once you get to this level of the stack, it's all private and can change from version to version and from device to device.
You also may find Brad Larson's response useful here:
iOS: is Core Graphics implemented on top of OpenGL?
You may also be interested in Chapter 6 of iOS:PTL. While it doesn't go into the implementation specifics, it does include a lot of practical discussion of how to improve drawing performance and best utilize the hardware with Core Graphics. Chapter 7 details all the developer-accessible steps involved in CALayer drawing.
Related
I'm creating an app where there're up to 40 UIViews where every view stores a drawing of a stick on it which is available in several positions, rotated to 30 degree angle, 45 degree angle etc). Background of a View is transparent. These views can intersect with each other, so I need the UIViews to be transparent in order a user could see both drawings from overlapped and overlapping view. I wonder if this affects a performance of an application seriously? (all this transparency of all 40 UIViews). And how I can track how much memory or CPU my app currently uses.
I recommend watching WWDC 2012 Session 238 - iOS App Performance: Graphics and Animations, which covers these questions.
As a broad answer:
The iPhone will probably handle your 40-view requirement fine—but its impossible to know for sure without trying it out, and without more context (are they being animated? Are they scrolling?)
More views creates more performance problems, because all of the views need to be packaged up and shipped off to be rendered (by backboardd I think).
Transparency will hurt application performance. I believe the core reason is that transparent views need to be drawn in an off-screen buffer rather than be painted over existing content (something like that).
Use Instruments for Profiling
Profile your GPU usage using the Open GL ES Driver (look at 'Device Utilization')
Measure CPU usage using Time Profiler
Measure FPS and check for common performance problems using the CoreAnimation instrument
I wouldn't bother thinking about this until you actually see performance issues. If you do, I can't recommend that WWDC session enough—it covers things like what strategy you should take to optimize performance (e.g. moving work to the GPU as long as it can handle more; the basics of profiling, etc.) as well as tips and tricks based on the implementation details of iOS.
I have a custom view (inherited from UIView) in my app. The custom view overrides
- (void) drawRect:(CGRect) rect
The problem is: the drawRect: executes many times longer on iPad 3 than on iPad 2 (about 0.1 second on iPad 3 and 0.003 second on iPad 2). It's about 30 times slower.
Basically, I am using some pre-created layers and draw them in the drawRect:. The last call
CGContextDrawLayerAtPoint(context, CGPointZero, m_currentLayer);
takes most of the time (about 95% of total time in drawRect:)
What might be slowing things so much and how should I fix the cause?
UPDATE:
There are no threads directly involved. I do call setNeedsDisplay: in one thread and drawRect: gets called from another but that's it. The same goes for locks (there are no locks used).
The view gets redrawn in response to touches (it's a coloring book app). On iPad 2 I get reasonable delay between a touch and an update of the screen. I want to achieve the same on iPad 3.
So, the iPad 3 is definitely slower in a lot of areas. I have a theory about this. Marco Arment noted that the method renderInContext is ridiculously slow on the new iPad. I also found this to be the case when trying to create a magnifying glass for a custom text view. In the end I had to forego renderInContext for custom Core Graphics drawing.
I've also been having problem hitting the dreaded wait_fences errors on my core graphics drawing here: Only on new iPad 3: wait_fences: failed to receive reply: 10004003.
This is what I've figured out so far. The iPad 3 obviously has 4 times the pixels to drive. This can cause problems in two place:
First, the CPU. All core graphics drawing is done by the CPU. In the case of rotational events, if the CPU takes too long to draw, it hits the wait_fences error, which I believe is simply a call that tells the device to wait a little longer to actually perform the rotation, thus the delay.
Transferring images to the GPU. The GPU obviously handles the retina resolution just fine (see Infinity Blade 2). But when core graphics draws, it draws its images directly to the GPU buffers to avoid memcpy. However, either the GPU buffers haven't changes since the iPad 2 or they just didn't make them large enough, because it's remarkably easy to overload those buffers. When that happens, I believe the CPU writes the images to standard memory and then copies them to the GPU when the GPU buffers can handle it. This, I think is what causes the performance problems. That extra copy is time consuming with so many pixels and slows things down considerably.
To avoid memcpy I recommend several things:
Only draw what you need. Avoid drawing anything offscreen at all costs. If you're drawing a large view, but only display part of that view (subviews covering it, for example) try to find a way to only draw what is visible.
If you have to draw a large view, consider breaking the view up in to parts either as subviews or sublayers (probably sublayers in your case). And only redraw what you need. Take the notability app, for example. When you zoom in, you can literally watch it redraw one square at a time. Or in safari you can watch it update squares as you scroll. Unfortunately, I haven't had to do this so I'm uncertain of the methodology.
Try to keep your drawings simple. I had an awesome looking custom core text view that had to redraw on every character entered. Very slow. I changed the background to simple white (in core graphics) and it sped up well. Even better would be for me to not redraw the background.
I would like to point out that my theory is conjecture. Apple doesn't really explain what exactly they do. My theory is just based on what they have said and how the iPad responds as well as my own experimentation.
UPDATE
So Apple has now released the 2012 WWDC Developer videos. They have two videos that may help you (requires developer account):
iOS App Performance: Responsiveness
iOS App Performance: Graphics and Animation
One thing they talk about I think may help you is using the method: setNeedsDisplayInRect:(CGRect)rect. Using this method instead of the normal setNeedsDisplay and making sure that your drawRect method only draws the rect given to it can greatly help performance. Personally, I use the function: CGContextClipToRect(context, rect); to clip my drawing only to the rect provided.
As an example, I have a separate class I use to draw text directly to my views using Core Text. My UIView subclass keeps a reference to this object and uses it to draw it's text rather than use a UILabel. I used to refresh the entire view (setNeedsDisplay) when the text change. Now I have my CoreText object calculate the changed CGRect and use setNeedsDisplayInRect to only change the portion of the view that contains the text. This really helped my performance when scrolling.
I ended up using approach described in #Kurt Revis answer for similar question.
I minimized number of layers used, added UIImageView and set its image to an UIImage wrapping my CGImageRef. Please read the mentioned answer to get more details about the approach.
In the end my application become even simpler than before and works with almost identical speed on iPad 2 and iPad 3.
Sometimes the term Graphics Context is a little bit abstract. Are they actually system resource, but they are resource from the Graphics Card, just like a file handle is system resource from the hard drive or any permanent storage device?
Just as a file handle has some states about whether the file handle is for read only or read/write, and the current position for the next read operating -- the states, a Graphics Context has states about the current stroke color, stroke width, or any relevant data. (update: and in write mode, we can go to any point in a 200MB file and change data, just like we have the canvas of the Graphics Context and draw things on top of it)
So Graphics Context are actually global, system-wide resource. They are not part of the application singleton or anything, just like a file or file handle is not (necessarily) part of the application singleton.
And if there is no powerful graphics card (or if the graphics card ran out of resource already), then the operating system can simulate a Graphics Context using low level graphics routines using bitmaps, instead of letting the graphics card handle it.
Is this how a Graphics Context work actually, on iOS and most other common OS in general?
I think it's best not to think of a Graphics Context in terms of a specific system resource. As far as I know, the graphics context doesn't correspond to any specific resource anymore than an any class 'object' does, besides memory of course. Really, the Graphics context is designed to provide a 'canvas' for the core graphics functions to operate on. The truth is, Apple doesn't give us the specific details of how a graphics context works internally. But there are several things we do know about it:
The graphics context is basically a 'state' more than anything else. It holds information such as stoke/fill color, line width, etc for a particular set of drawing routines.
It doesn't process on the GPU. Instead it processes (does all it's drawing) on the CPU and 'passes' the resulting image (some form of a bit map) to the GPU for display/animation (actually it renders the image directly to the GPU's buffers). This is why the 'renderInContext' method isn't working so well in the new iPad 3. renderInContext gives you the image first, which involves rendering and copying the image. If you wish to then display it, it must be passed back to Core Graphics which then writes the image back out. On the iPad 3, this involves a lot of memory (depending on the size of the view) and can easily overflow buffers.
The graphics contexts given to the 'drawRect' method of UIView is designed to provide a context that is as efficient as possible. This is why you can't draw anything in a view outside a context, nor can you create your own context for a view to draw in. The actual drawing is handled in the run loop, which is why we use this method to flag a UIView as needing to be drawn: [view setNeedsDisplay].
The graphics contexts for UIViews are drawn on the main thread and yes, again, processed on the CPU. This does mean overly complex drawings can tie up your main application, but now days with multi-core processors that's not so much of a problem.
You can create a graphics context, but only to draw to draw to an image. This is exactly the same thing as what a UIView context does, except that it's meant to be used by you rather than drawn to the screen or animated. Since iOS 4, you can process these image contexts in other threads (besides the main thread).
If you're looking to do GPU drawing, I believe the only way to do this is to use OpenGL if you're using iOS. If you're using MacOS, I think you can actually enable Quartz (core-graphics...same thing) drawing on the GPU using QuartzGL. But it may not be worth the effort, see this article: Mac QuartzGL (2D drawing on the graphics card) performance
Update
As you can see in the comments below, the current arrangement Apple has for Quartz drawing is probably the best, especially since views are drawn directly to the GPU buffers. There is a temptation to think that processing anything visual should be done on the GPU but the truth is, GPU's aren't designed for vector drawings. They're designed to handle massive transforms, lighting, texture mapping, etc. By using the CPU to process vector drawing and leaving everything else to the GPU Apple has split the graphics processing appropriately. Moreover, you're not loosing any efficiency in the data transfer between the CPU and GPU since Quartz is drawing directly to the GPU's buffer (which avoids that onerous memcpy).
Sometimes the term Graphics Context is a little bit abstract.
Yes, intentionally so. Quartz is meant to be an abstraction, a general-purpose drawing system. It may or may not perform some optimizations with the graphics hardware, internally, but you don't get to have much visibility into that. And the kinds of optimizations it makes may change over time and with different kinds of graphics hardware.
Are they actually system resource, but they are resource from the Graphics Card
No, absolutely not. Quartz is a software renderer -- it works even when there is no graphics hardware present, and can draw to things like PDFs where the graphics hardware wouldn't be of any use.
Internally, Quartz (and its interfaces with the rest of the OS) may have a few "fast paths" that take advantage of the GPU in some situations. But that's by no means the common case.
Just as a file handle has some states about whether the file handle is for read only or read/write, and the current position for the next read operating -- the states, a Graphics Context has states about the current stroke color, stroke width, or any relevant data.
This is correct.
So Graphics Context are actually global, system-wide resource.
No. Quartz is just a library that runs code within your app. If you make a new CGContext, only your app is affected -- exactly the same way as if your code created a new instance of one of your own classes.
And if there is no powerful graphics card (or if the graphics card ran out of resource already), then the operating system can simulate a Graphics Context using low level graphics routines using bitmaps, instead of letting the graphics card handle it.
You have the two cases flipped. In general Quartz is working in software, with bitmaps. In a few cases, it may use the GPU to get those bitmaps on the screen faster, if everything is lined up exactly right.
I heard that for a single view app, it is best to keep the current main view's content in a bitmap, and we paint extra things on this bitmap, and when it is time to do drawRect (when called by iOS), then we just display the bitmap.
Is it true that Core Graphics is quite capable of handling it? But since both cocos2D and OpenGL ES are said to be super fast when handling graphics, is using one of them good for the situation above, making it more smooth or is it not that different from using Core Graphics?
(Or maybe it matters for type of application, such as a simple drawing program, versus a game that refreshes 30fps or 60fps?)
It depends if you need to draw every frame and have your drawings change.
Check out the AccelerometerGraph sample code provided by Apple. This is one way of using Core Animation layers and Core Graphics (Quartz drawing) together to do continuous drawings across many frames without redrawing what has already been drawn.
Cocos2D is less for drawing and more for sprite-based animations where your sprites are pre-rendered images that you have imported (png, etc). It's very very fast at handling multiple images simultaneously and offers batch nodes for consolidating all images to just one single Open GL call.
Quartz (Core Graphics) by itself is not usually the best option for continuous drawing, but is better for generating static images once that you then move around, if necessary.
I am wondering if what I'm attempting is just a bad idea. I'm currently working in monotouch. Is it possible to draw a screen-sized (on my iPhone 4 its about 320x460) buffer onto a UIView of equal size fast enough so that animated changes to that buffer look smooth to the end user (need it to be around 20ms per draw).
I've attempted many different implementations. The best one so far seems to be using an in-memory CGLayer and calling context.DrawLayer() to apply it to the view inside of Draw(). But even that takes 30-40ms per DrawLayer.
I'm writing my own tile-image control, and aside from performance, the idea is working well. I just can't figure out how to get the buffer onto the UIView fast enough.
Any ideas?
I've been dealing with custom views a lot lately, and i've had a bunch of performance problems, too.
All of these performance issues could be solved by determining the elements that need to be redrawn, and, more importantly, the elements that do not need to be redrawn.
Then, split the contents in the layer into individual sublayers and only redraw them if necessary. The good thing is, animations and so on are very smooth for those individual layers. (Their content is only a simple bitmap and does not change until you tell it to).
The only limitation i've come across was, that you cannot use CG blend modes (e.g. multiply) for the sublayers. As far as i know that is not possible. You can only use those blend modes inside the CG code used to draw the contents of the sublayers, but after that they are all composed in "normal" mode.
It really depends on what you are drawing.
If you are just drawing a solid filled color, that should not be a problem. The question is how much of the surface you are changing, and how you are changing it.
Again, it depends on what you are drawing and whether you could offload some of the work to the GPU. For example if you have static parts of your interface that will remain the same, or are animated/updated independently, you could use a different layer for those areas and let the GPU compose those.
Layers have the advantage that they are composited by the GPU, and they are backed by their own bitmaps. Once you draw into the surface of the layer, the OS will cache the result in the GPU and compose all of your layers at the same time.
Then you can determine which parts of your application actually need to be redrawn and only redraw those sections on each frame.
But again, it really will depend a lot on what you are trying to do.