My question might be answered somewhere but I just couldn't find solution after a long research.
I need to draw visually shapes (curves, lines, rectangles etc.) on iPhone one on top of the previous. I did that using CGContext to draw over an image and it's working fine. However in my app the drawing view resizes on device rotation and the lines become blurred because of the different image size.
That's why I subclassed UIView and to call setNeedsDisplay from touchesMoved and touchesEnded. In drawRect I'm passing the point and... almost everything works OK.
However I have two problems:
1. Every time drawRect is called it clears previous drawing and starts over so I can't add a new shape.
2. Second is followed by same thing - I can't make a curve as on every move drawRect is called and the previous point is dismissed and a line is added from the starting point to the current.
So am I doing the whole thing wrong and is there some other better approach to this.
Thanks in advance!
Related
I have a UIScrollView that contains a custom UIView. In my UIView I am overriding drawRect to draw a path using CGContextStrokePath. I would like to slightly alter the way the zoom works. Pinch zooming out will show more of the paths on the screen. This is what I want but i want the line width to stay the same not shrink as you zoom out so that they are still clear to the user.
I thought I would just do this (myUIView zoom target is called _lineView)
-(void)scrollViewDidZoom:(UIScrollView *)pScrollView
{
_lineView.zoomScale = _scrollView.zoomScale;
[_lineView setNeedsDisplay];
}
and then just calculate an appropriate line stroke size in my _lineView drawRect method to give the effect of constant line width as you zoom out.
This is really slow and I have read that this is expected as drawrect is not optimised to be called many times a second.
I then started looking at using a GLKView instead and just rendering the whole thing in opengl directly. The problem with this is I will have to implement all of the zooming and panning myself (with all the lovely zoom and pan bounce effects you get for free in UiScrollView). I will also have to implement all the controls I want to use in opengl, buttons etc.
Is there a way to do this whilst still using Quartz2d? I feel like opengl will give me lots of power but it will take me much longer to get the rest of my app done if I go down that route.
I figured this out. I found a simple way to do this that does not slow down the zoom / bouncing animations at all and is very fast and fluid.
Quartz has a class called CAShapeLayer that lets you do some pretty cool stuff. Among these is being able to set a CGPath property and specify a linewidth. Changes are reflected in the view.
So i basically call shapeLayer.lineWidth from my scrollViewDidZoom method and it does exactly what i need.
What I would do if I were you is to use default zooming behavior while zooming (which does not redraw, but instead just applies a transform to the zoomed view, which can be done by the GPU very, very quickly, but as you have noticed can lead to inferior quality).
Then, when the user finished zooming, redraw the whole view as you do now. The appropriate delegate method is scrollViewDidEndZooming:withView:atScale:.
This way, you have fast (but slightly ugly) zooming, and nice (but slightly, probably unnoticeably, slower) display after the zoom is finished.
My question is very similar to this one Not drawing outside bounds when clipToBounds=NO which received no clear answer.
Basically I have a UIView, and I want to draw a line from the center of it, to the edge of the screen. Calculating where these points are is easy, using [self convertPoint:(CGPoint){0,0} fromView:[self superview]]; (which finds the origin with respect to my view's superview. But when I draw a line from my view's drawRect: it gets clipped at my view's bounds.
Is there a way to draw outside of my view's bounds? I've tried changing the clipsToBounds property, but it doesn't seem to have any effect.
I can't draw my lines from the superview because I need to do this with multiple views and some will be in front of others... figuring out the layer from the superview's drawRect seems like a bad idea.
Similarly, I don't think I can just resize my view's bounds to include the entire screen, because my views need to be dynamically re-sizable... the bounds would have to be HUGE (>20,000 points square) for this to work.
I wouldn't recommend ever drawing outside of a view's bounds. Either your view needs to resize automatically to include your drawing or you need to have transparent overlapping views. Or both. I can't think of a situation that either of these cases wouldn't cover, but I may lack imagination. =)
Likely what is happening currently is that when the super view gets redrawn it tells the super view that it needs redrawn, resulting in erasing the drawing you are doing outside. It's been a while, anyone more knowledgeable can (should!) correct me here if I'm wrong.
I don't know if "Quartz Debug" (from the standard apple developer tools install, /Developer/Applications/Performance Tools/Quartz Debug) works in the simulator, but it's worth a try. It has a mode that will show you when and how often redrawing takes place, with a border and optional delay on the refreshes.
You can do what you are asking, but you need to force redraw your sub-views every time you go outside the sub-view's bounds, meaning that your super-view needs to manually draw it's children inside of it's draw function. Essentially you would be throwing out apple's drawing paradigm and simply causing your sub-views to act like a drawing extension of your main view anyway.
Additionally, if your ranges are so dynamic you may want to consider drawing in percentages of the screen or super-view rather than in points, it may make more sense to code.
I'm writing an application that uses your finger to draw simple diagrams. I have it working for the most part but now I'm trying to optimize its performance. When the user swipes their finger fast, I can't capture enough touch events to draw a smooth path.
Here's my current approach:
1) I subclassed a UIView and added a poroperty to a CGLayer (gets created lazily and is the same size as my UIView).
2) My UIView subclass responds to touch events by storing the current and last touch points in instance variables.
3) My view's setNeedsDisplay is called and in the draw rect , do the following:
- draw a line from the previous touch location to the current touch location to the CGLayer
- draw the entire CGLayer to my views context in one go
The main problem is when a user swipes fast I get relatively few touch events, so the lines I draw between the touches are long and makes the path look jagged not smooth.
My questions:
1) Does drawRect (on my UIView subclass) and my touch event handlers on my UIView subclass get called in the same thread? I.e. could I have to threads executing (one in a touch event and the second in my draw rect)?
If no - do touch events get queued up while drawRect is being called? And how can I improve performance - simply improve performance of drawRect?
If yes - how can I get more touch events to happen so I can draw a smoother path?
Thanks.
Another approach is to interpolate the curve between the sample points. When the finger drag starts, begin collecting sample points. As the number of points increase, redraw the line. With two points, draw a straight line, with three or more draw a curve. You can re-start the process when two points are sampled that lie within a defined distance. This would allow you to draw two arcs (like a 'm') in one motion - you naturally pause in the middle as you change direction, possibly long enough for two or more samples.
drawRect gets called on the main thread. But you don't have to do this. You can use the main thread to collect UI events and do the drawing on a background thread. The background thread gets notified whenever there are new touches and starts a drawing operation in its own CGBitmapContext. Then you create a CGImage and hand it over to the View: view.layer.contents = drawingImage.
If you need even more performance, consider drawing using OpenGL.
Aloo, did you have find a solution to his as I've got the same problem. I also found agreat tutorial http://www.ipodtouchfans.com/forums/showthread.php?t=132024 but it also has the same problem that if you draw fast, say a circle, the drawing isn't very smooth. It;s almost like the iPhone just can't keep up, unfortunately this has to use the core graphics stuff.
Have you tried this?
http://developer.apple.com/library/ios/#samplecode/GLPaint/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007328-Intro-DontLinkElementID_2
I tried adding
CGContextSetLineJoin(UIGraphicsGetCurrentContext(), kCGLineJoinRound);
but this did nothing. Looks like we'll have to figure out bezier curves
All,
I'm having trouble getting behavior that I want from CATiledLayer. Is there a way that I can trigger the tiles to redraw without having the side-effect that their areas are cleared to white first? I've already subclassed CATiledLayer to set fadeDuration to return 0.
To be more specific, here are the details of what I'm seeing and what I'm trying to achieve:
I have a UIScrollView with a big content size...~12000x800. Its content view is a UIView backed by a CATiledLayer.
The UIView is rendered with a lot of custom-drawn lines
Everything works fine, but the contents of the UIView sometimes change. When that happens, I'd like to redraw the tiles as seamlessly as possible. When I use setNeedsDisplay on the view, the tiles redraw but they are first cleared to white and there's a fraction-of-a-second delay before the new content is drawn. I've already subclassed CATiledLayer so that fadeDuration is set to 0.
The behavior that I want seems like it should be possible...when you zoom in on the scrollview and the content gets redrawn at a higher resolution, there's no blanking before the redraw; the new content is drawn right on top of the old one. That's what I'm looking for.
Thanks; I appreciate your ideas.
Update:
Just to follow up - I realized that the tiles weren't being cleared to white before the redraw, they're being taken out entirely; the white that I was seeing is the color of the view that's beneath my CATiledLayer-backed view.
As a quick hack/fix, I put a UIImageView beneath the UIScrollView, and before triggering a redraw of the CATiledLayer-backed view I render its visible section into the UIImageView and let it show. This smooths out the redraw significantly.
If anyone has a better solution, like keeping the redraw-targeted tiles from going away before being redrawn in the first place, I'd still love to hear it.
I've found that if you set levelsOfDetailBias and levelsOfDetail both to the same value (2 in my case), then it only redraws the tiles that are touched by my setNeedsDisplayInRect: call, as you'd hope.
However if the levelsOfDetail is different to LODB, then any calls to setNeedsDisplayInRect: redraw all the tiles.
You could add another layer (possibly a CATiledLayer) behind the existing tiled layer. (Sort of a double-buffered solution.) You would call setNeedsDisplay: on the second layer from a timer that fires after a few seconds to ensure that that layer doesn't redraw at the same time as the front layer.
Another potential option is to use the same delegate to draw content to a bitmap context and swap the bitmap into the backing store once the content is refreshed. This should produce a flicker-free result. That being said, I can't tell you how this might be done, and one nice thing about CATiledLayers is they automatically generate tiles when you zoom and pregenerate tiles when you pan once zoomed in.
I would like to see how you implement your application. I have been looking for weeks to find an example that uses a combination of UIScrollView and a CATiledLayer-back view with a lot of custom drawn lines. Apple has some great sample code - but it all involves images rather than line art, so no help for me.
Having read through these answers without a solution, I discovered that tiling a page was the dominant background task.
Preparing my lo-res placeholder image on a high priority queue solved this issue - the images now appear while the tiling is occurring. Caching the placeholder images further improves their appearance - they appear before the tiling begins.
With newer devices, the tiling it so fast, these tricks might not matter. A sample PDF consisting of large scanned images (e.g. a scanned book) tiles the slowest in my experience, and makes for good test data.
I had the same problem with iPad.
The solution was more simple than I thought and far more simple than using UIImageView to render display before redrawing... :
Just don't set any background color for the Layer!
I had CATiledLayer set in a similar way:
layer = [[CATiledLayer alloc] init];
layer.masksToBounds = YES;
layer.contentsGravity = kCAGravityLeft;
//layer.backgroundColor = [[UIColor whiteColor] CGColor];
layer.tileSize = CGSizeMake(1004.0, 1004.0);
layer.levelsOfDetail = 16;
layer.levelsOfDetailBias = 8;
Note that I have commented out the line setting layer's background color to white.
After that the white blank before redraw problem disappeared!
Let me know if anyone has tried that.
Everytime UIView's drawRect is called, the content drawn by previous drawRect (using Core Graphics) is cleared out. How can I make it so that the paths rendered from previous drawRect calls stay until I explicitly clear it?
You basically need to clip the 'dirty' part of your rect where changes have been made, and only this part will be re-drawn.
- (void)setNeedsDisplayInRect:(CGRect)invalidRect
I'm fighting this issue myself right now. The problem is there is a property on the UIView called "clearsContextBeforeDrawing" that according to the documentation is supposed to fix this problem, however it doesn't work that way in my experience.
I think ultimately the solution to this is going to be to allocate an offscreen buffer and do all my drawing there, then blt it over to the UIView in the drawRect method.
I'm pretty certain there's no way around this; it's how UIView is designed to work. If asked to, your custom view should be able to draw any part of itself at any time. This is partly because views can do more than just appear onscreen. e.g. on the desktop they can be printed, and even on the iPhone, you might wish to capture the contents of a view to a bitmap.