I have a UIScrollView with a tableview inside. Long story short, my UIScrollView's frame is being adjusted despite the fact that I'm not physically setting the frame anywhere. What I'm specifically wondering is are there any other changes you can make to a UIScrollView that will adjust the frame w/o actually manually setting the frame. I'd post some code, but I'm working on a very large codebase and I can't drop in any specific code. The reason why I'm confident that the frame isn't being programatically set is that within the ~3k or so lines of code that are being executed, setFrame or .frame = for the scrollView isn't being called. Anyways, any insight into anything else adjusting the frame as a side effect would be great. Thanks guys.
Related
I've got a UIView with a UILabel on top. I have the UILabel's content mode set to 'UIContentModeLeft'. As expected, when I animate the frame of the UIView to be smaller than the original size, the label 'jumps' to the final frame without animating nicely.
As far as I can see, UIContentModeRedraw does not force 'drawRect' to be called on every 'animated frame'. I've tried using a custom CALayer as well but can't seem to cause the frame to resize smoothly.
Is there any way to do this? The animation as it stands is extremely glitchy. UIContentModes are not useful and I can't use a frame for contentStretch as well as none of the edges of the label can be stretched. What I really need is a 'refresh' of the label every time the parent view resizes.
There's no way of doing this unfortunately, so I've learnt. The only other way is to actually run a timer that updates the frame every time it's invoked. This results in a very jerky animation given a resize of a complex view is time consuming. I ended up achieving the same thing with some pre-rendered onscreen elements and a whole lotta 'magical effects' behind the scene.
I have an EAGLView which I am resizing in an animation, with the animation driven by an NSTimer that calls a draw function. As I resize the EAGLView, I need to adjust the projection for the view to maintain the aspect ratio of the contents. The draw function looks like this:
gameView.frame = newFrame;
[gameView setFramebuffer];
[self updateProjection];
/* Drawing to the EAGLView, gameView, here, then... */
[gameView presentFramebuffer];
Run like this, though, the contents of the EAGLView appear to "stair-step" down the animation. When I record it and look at it frame by frame, it's clear that the projection is adjusted, then the view is resized a very short time later (less than one animation frame).
I suspect that the reason is that the change in the frame of gameView is being deferred, and that in the meantime the updated framebuffer is making its way to the screen. I've tried using CATransactions to get the frame update to take effect immediately, but as I kind of expected for a UIView change, that did nothing. I suppose I could modify the viewport and leave the EAGLView full-frame, but I worry that that might just leave me with synchronization issues elsewhere (say, with updates to any overlaid CALayers).
Does this seem like a reasonable assessment of the problem? How can I prevent it -- that is, how can I best ensure that the framebuffer presentation coincides with the change in the actual frame of the EAGLView (and other CA elements)?
Thanks!
I encountered a similar issue with a custom EAGLView I wrote. The problem was that when changing orientation, the view got resized and the contents stretched, and only after the animation, the scene with the right proportions was displayed.
I think yours is the same problem, and I don't think you can force CoreAnimation to wait for your view to update before rendering an animation frame, because of the way it works (CA isn't aware of the drawing mechanism of the view or the layer on which operates).
But you can easily bypass the problem: open you xib file containing the view, switch to the attributes inspector on the right. Select your EAGLView (the same applies to GLKView), and under the section View there's the Mode attribute. If you're creating the view programmatically, set the contentModeproperty.
This value describes how the view contents are managed during an animation. Until the buffer is displayed, the old scene gets resized according to that mode; perhaps you can find a mode that fits the animation you need to achieve.
If you're worried about proportions, the center content mode may work, but the part of scene that hasn't been rendered yet will appear empty during the animation.
Unfortunately the redraw mode won't necessarely make your EAGLView refresh: the view is actually redrawn, but potentially with the old contents of the color buffer. It's a problem of getting the buffer filled at the right time.
You could try to resize and prerender a frame big enough to cover the whole animation before starting it; or you could try to render a frame to an UIImage, replace the view on the fly, animate it, the place the EAGLView back, but this may seriously affect performance.
The way I solved my issue was making simply the EAGLView big enough.
Regarding the blending of other CALayers, as far as I tried, I encountered no synchronization issue; the EAGLView updates when it can, and the other layers too. Just set the right properties to CAEAGLLayer if you're using alpha channel, and rememeber that blending the layers every time OpenGL updates your scene may be expensive in terms of performance.
I have a UIToolbar in IB with a custom UIBarButtonItem that is set to an image. The image height is larger than the UIToolbar height. The image does not load for some reason. Attached is a screenshot.
You should avoid using subviews that are larger than the parent view - even if it does work and draws the view outside of the bounds, you cannot always count on it because the clipping is skipped for performance reasons and depending on the drawing order the overlapping part of the subview might be covered later. Second problem is that only the part within the frame of the superview is able to handle the touch events.
As to why you don't see your image, it's probably a different problem, I doubt it has something to do with it going outside the frame. Post your code to get more feedback ;)
I have a UITextView with scrolling disabled, and I am using the page-curl transition to change the text inside. This is the code I'm using:
myView.text = nextString;
[UIView transitionWithView:myView duration:PAGE_CURL_DURATION options:UIViewAnimationOptionTransitionCurlDown animations:nil completion:nil];
Everything works fine, except if the new text string has more lines than the old one, it will be clipped until the animation is complete. It looks as though the contentSize is changing AFTER the animation. I tried adding myView.contentSize = myView.bounds.size; but that didn't change anything. I also turned off "clip subviews" to no avail.
This is what it looks like immediately after the animation:
a moment later the text is no longer clipped.
Any ideas how to prevent clipping?
The easy way is to do what Bjarne said - use the clipsToBounds property. But watch out - this will make the text expand downwards indefinitely. So you will also need to surround your text field with a container view that DOES clip to bounds to set an upper limit.
If that doesn't do the trick, you will have to do some work to manually expand your text view's bounds and reposition it before animating if the new text is larger.
To get the size of a text, check out UIStringDrawing.h in the UIKit framework. Specifically, I'm thinking of using:
- (CGSize)sizeWithFont:(UIFont *)font forWidth:(CGFloat)width lineBreakMode:(UILineBreakMode)lineBreakMode;
together with UILineBreakModeWordWrap.
another alternative to getting the size may be this function in UILabel:
- (CGRect)textRectForBounds:(CGRect)bounds limitedToNumberOfLines:(NSInteger)numberOfLines;
and passing in the bounds of the largest possible text view.
For extra credit, you may also want to consider animating the change in your view's bounds for a smoother transition.
This is rather odd. The contentSize should not clip contents, but only determine scrolling behavior. This however is the only thing changing from pre- to post-animation. And unchecking Clip Subviews always worked for me.
A few options:
I assume your UITextView.frame is large enough to contain the largest of both texts initially? If you set it just before the animation kicks in, you might be too late. In such cases tricks like [self performSelector(continueWithStuff:) withObject:object afterDelay:0.01] do wonders, because you give the UI the time needed to effectuate your changes before the animation will determine the initial state.
But the easiest fix by far will be to add a bunch of newlines to every text. Since you're not scrolling anyway this should not be a problem.
Another angle may be to embed your UITextView in a UIView which you then animate. Reading the docs, the view argument should be "The container view that contains the views involved in the transition." Ignoring this fact may be giving your surprising results.
The easiest way to fix you problem is to set the UITextView's property "clipsToBounds" to NO. This will make your text view available to draw outside of its bounds
I have looked at UIScrollView. Any thoughts on implementing "infinite" scroll/zoom?, but it didn't exactly address my issue. I'm puzzled, though, because I would guess that other folks haven't seen my problem, so maybe it has to do with the details of my code. The sample code provided by Allisone is similar to mine, although I use scrollViewDidScroll to monitor the contentOffset instead of custom KVO approach.
When my UIScrollView is decelerating, if I insert a subview to the left of the UIScrollView's bounds and increase contentOffset by the width of my inserted subview, my change to contentOffset is ignored; the content "jumps" by the width of the inserted subview, and the contentOffset value stream continues on its current trajectory in subsequent invocations of scrollViewDidScroll. While simply tracking, there is no problem. Is there something I'm likely to be doing wrong? It's almost as if the bounds or contentOffset is sticky with regard to the deceleration events.
Use case: the UIScrollView has very large virtual content that is dynamically paged in and out, and when the user is smoothly scrolling through content in the UIScrollView (toward the left, say), additional content should be inserted on the far left of the scrollview without disrupting the smooth scrolling that is currently going on. As I said, this works fine if deceleration is disabled or I rely on dragging rather than flicking.
At first I hoped that the problem was caused by changing the contents of the UIScrollView from within the callout to scrollViewDidScroll, so I double-checked by doing a delayed performSelector, but the problem remained.
Thanks,
Kevin
Even though not exactly what you had in mind, but using setContentOffset:animated will have the desired outcome ( alter the content offset to the right coordinates ) although it will be animated.
Faced up with the same issue. Seems like strange UIScrollView bug. I fixed it on the base of StreetScroller example from Apple. InfiniteScrollView inherits from UIScrollView and works good in there. But if you want to create custom class which uses UIScrollView inside itself, you can subclass this UIScrollView and call delegate when it needs to recenter content like this:
tScrollView : UIScrollView
In tScrollView.m:
- (void)recenterIfNecessary {
if (_tDelegate && [_tDelegate respondsToSelector:#selector(offsetForRecenterScrollView:)])
self.contentOffset = [_tDelegate offsetForRecenterScrollView:self];
}
- (void)layoutSubviews {
[super layoutSubviews];
[self recenterIfNecessary];
}
Implement offsetForRecenterScrollView: in delegate and return new CGPoint to set in scrollView.contentOffset.