I've got this giant UIView with around 600 UIButtons as subviews. The UIView is about 2000 by 2000 pixels and it's a subview on itself for a UIScrollView. I'm trying to implement CATiledLayer as the rendering layer for this giant UIView but I can't seem to figure out how to render the tiles. I found a lot of examples that cover CATiledLayer with tiled images, pdf's, ... but I never found a real example on how to draw a complete UIView with a lot of subviews. You're probably asking why i'd like to stick with UIView? Because I'd like the users to keep on using the buttons to interact with the view.
I'm wondering if someone has an example or some psuedo code on how to implement the - (void)drawLayer:(CALayer*)layer inContext:(CGContextRef)context method, keeping in mind that there's 1 giant UIView with a lot of UIbuttons as its subviews.
Starting with iOS 4.0, you can use drawRect: instead of drawLayer:inContext:. This Q&A from Apple explains it: http://developer.apple.com/library/ios/#qa/qa1637/_index.html. The important point from it is that drawRect: in 4 is now thread-safe and you can use UIKit graphics functionality.
You still need to override this method to use a CATileLayer:
+(Class)layerClass
{
return [CATiledLayer class];
}
But you can now just use drawRect:
-(void)drawRect:(CGRect)rect
{
//normal drawing routines here.
}
The rect that is delivered to the method will be the size of your tiles and you need to determine what needs to be drawn in the particular rect. The power of CATiledLayer is that it only calls for drawing the tiles that are showing on the screen. It also uses background threads and is very fast.
I have not used CATiledLayer with UIViews, only large images. Are the UIViews subclasses with their own drawRect: implementations? I think you will need to determine which views will be showing in the current rect and call their drawRect: method.
Using drawRect: is only for iOS 4.0 and later, it won't work for older versions.
Related
I need to improve the scrolling performance of a view for annotating on top of an image.
Currently I have the following:
- annotationView (custom NSView)
- imageView (NSImageView)
- contentView (custom NSView)
- clipView (NSClipView)
- scrollView (NScrollView)
The images are quite large PDFs and PNGs and scrolling is poor unless I make the imageView layer backed, which I am just doing in Interface Builder. Scrolling is then pretty smooth.
However the PNG images override everything on top of the imageView, whereas the PDF images remain correctly in the background.
Why is this and how can I fix that?
To get even better performance I would also like to make the annotationView layer backed as well but if I do that the entire view becomes black - with the exception of the annotations being draw on the annotationView. How can I make this layer backed view transparent but still allow for the shapes to be draw on it. It seems I can make it transparent but then everything becomes transparent, including the drawn shapes.
Is there a better way to achieve this? The annotations are simply shapes and text that need to be placed at specific positions over the image which I am currently just drawing in response to mouse positions.
The short answer is to use layer backed views and use CGContext for drawing and not the simpler NSView drawing APIs.
By default macOS does not use GPU based graphics, unlike iOS.
macOS provides a high level API that uses the CPU rather than the GPU for graphics operations.
So in my case I switched everything to layer backed NSViews - you can set this in Interface Builder or simply add 'wantsLayer = true' in the NSView initialisation code (init()).
Avoid using NSImageView, instead use a layer backed view and set the layer.content = NSIMage, you may have to also set the layers background colour or you might get some areas of the background not being cleared when scrolling.
This works for me - I have big PDF images in the background - building layouts and a layer backed view on top of that for placing annotations.
Scrolling around is now buttery smooth. Images seem to load instantly.
For the most part its pretty easy - just set up right from the start and save yourself a lot of headaches.
I have a NSView with three NSImageView subviews. I'm having trouble with the subviews clipping when I use CATransform3DMakeTranslation to translate along the x axis.
I primarily do iOS development and this is my first go in this realm. Any help would be greatly appreciated.
I ended up having to turn the Core Animation Layer on for the content view of my window. I found the answer here: How to make NSView not clip its bounding area?
I'm working on some other person's code, which does most of the UI drawing in drawRect:. However, I need to add some animations (UIActivityIndicator animating, for example) to the view, and since drawRect: appears to be frame based, there doesn't seem to be an easy way.
I understand it is a mistake to fiddle with view hierarchies in drawRect, so I can't simply addSubview:. I want the activity indicator to do its own drawing, after drawRect:, because it should overlap. How should I approach this?
I've got a UIScrollView with a (custom) UIView inside of it.
In my scrollViewDidScroll-method I'm calling
[myCustomView setNeedsDisplay];
This makes the scrolling noticeably slower, if I'm implementing the drawRect: method in my custom UIView - even if it's completely empty.
As soon as I delete the drawRect: method, it's smooth again.
I have absolutely no idea, why... anyone of you?
I hate drawrect too
"It's because of the way hardware-accellerated animation works in Cocoa.
If you don't have a custom drawRect method, the system caches the pixels for your view in video memory. When it needs to redraw them, it just blits the pixels onto the screen.
If you have a custom drawRect method, the system instead has to call your drawRect method to render the pixels in main memory, then copy those pixels into video memory, THEN draw the pixels to the screen for each an every frame. The docs say to avoid drawRect if you can.
I think main memory and video memory are shared on most/all iOS devices, but the system still has a lot more work to do when you implement a drawRect method for a view.
You would probably be better served to use an OpenGL layer and render to that with OpenGL calls, since OpenGL talks directly with the display hardware."
link to that quote: http://www.iphonedevsdk.com/forum/iphone-sdk-development/80637-drawrect-makes-scrolling-slow-uiscrollview.html
In core animation or in App kit When we say layer-backed view or simply add a layer in the view,then actually what we mean by the layer.
A simple Google search:
The CALayer is the canvas upon which everything in Core Animation is painted. When you define movement, color changes, image effects, and so on, those are applied to CALayer objects. From a code perspective, CALayers are a lightweight representation similar to an NSView. In fact, NSView objects can be manipulated via their CALayer. This is referred to as being layer-backed.
A CALayer is an object which manages and draws upon a GL surface, and can manipulate that surface's location in three dimensions, without needing to redraw its contents.