Keeping backing CAGradientLayer static when UITableView scrolls - cocoa-touch

I'm trying to use a CAGradientLayer as a background for a UITableView. Everything works well until the overlaying view is scrolled, at which point then the pre-rendered background scrolls up and out of the way along with the original screen of data.
This is code that is being migrated from an iOS 3.1.3 app using a UIImage as a background to something device/resolution independent-looks great, works well, but sniffing the device type and using an alternate png isn't the sort of code that I want to ship, much less maintain.
Any suggestions as to how to do this?

Found the solution to what I was trying to solve, courtesy of Matt Gallagher:
http://cocoawithlove.com/2009/08/adding-shadow-effects-to-uitableview.html
His blog post has quite a few nice touches, including shadowing relevant cells instead of the whole table (mentioned as a performance issue in Noah's response).

You may have to make the table view transparent, and add the gradient layer to the table's superview. Keep in mind that your scrolling performance is probably going to be hideous—Core Animation will have to composite every subview of the table for every frame it displays. You may be able to slightly mitigate this by setting the cells' layers to rasterize themselves, as described here, but expect things to be pretty choppy regardless.

Related

Major NSTextView Rotation Problems

Bear with me on this one, as it's been frustrating me for a few days. This seems like it should be really simple, but for some reason I keep running into a series of frustrating problems. I've done more work on iOS in the past, and never had these kinds of problems that I'm having on OS X. I'm wondering if I'm not understanding something fundamental about the view architecture in AppKit. In particular, I am not very familar with the interaction between layer-backed views and plain views as I have not needed to animate anything on OS X before (and because iOS makes all views layer-backed by default).
Anyway, I'm having some major problems with trying to rotate an NSTextView object by 45 degrees. The text is for some labels that get placed in a larger custom NSView subclass, but most of that seems irrelevant to this specific problem. I'll go through what I've tried and the problems I had. The position of the labels is basically static, so I don't care about whether or not they are animatable or not. The labels need to be created and placed programmatically, not from IB, as their size and position is dependent on dynamically generated data. If it matters, the NSTextViews are using attributed strings.
1) I first did this the way that seemed most straightforward to me, which was simply to set frames for the NSTextView labels, added them as subviews to the graph object, and then called [labelTextView setFrameRotation:45] on them. This worked perfectly on Mountain Lion, but when I tested it on Lion the label height that gets drawn on screen gets increased mysteriously (even though when I log the frame afterwards it is unchanged). That isn't acceptable because I need it to draw a background color for the label so that it looks readable when overlaid onto the graph. So on Lion there is a bug or something in setFrameRotation as applied to NSTextView (or so it would seem). Does anyone know what is going on with that? It's very annoying that it works correctly on 10.8 but not on 10.7. SetFrameCenterRotation has the same problem. Making the view layer-backed, or not, seems to make no difference.
2) I next tried to do this using CATransform3DMakeRotation, after making the parent view and the NSTextView layer-backed. I used the line labelTextView.layer.transform = CATransform3DMakeRotation(M_PI_4, 0, 0, 1.0);, but the text view doesn't rotate when I do this. As a test, I tried the same thing using a plain NSView with a colored background, and it does rotate correctly. Does anyone know possible reasons why this wouldn't work with an NSTextView?
3) I tried enclosing the NSTextView in a NSView container and then calling setFrameRotation on that. This does rotate it correctly, but somehow triggers an infinite recursion in Core Animation that quickly consumes gigabytes of RAM unless I kill the process! Again, any ideas about what's going on there?!?
4) I tried all of this using Autolayout to position the labels AND positioning them manually by setting their frames. No differences in results either way.
5) I could do this using completely custom drawing, but that would be a LOT of work in this particular case. I'd rather not do that just to support 10.7. I also could try NSTextField to see if it suffers from the same thing in part 1), but that would be annoying because I want some of the features of NSTextView (this isn't just a single line blob of text).
What am I doing wrong here? I never imagined something this simple being this difficult to get working correctly on 10.7 + 10.8.
UPDATE:
I tried substituting NSTextField for NSTextView and the problem in 3) goes away (the paragraph styling isn't exactly how I want it yet, but I can possibly fix that). Any ideas on why NSTextView has such problems with being rotated where NSTextField apparently doesn't? That seems insane to me. I'll try NSTextField without the container next to see if it also suffers from the drawing glitch on Lion.
UPDATE 2:
I tried just using an NSTextField instead of an NSTextView and rotating it, and that also worked completely fine on both Lion and Mountain Lion. The visual glitch where the size of the text view changes after rotation also disappears. So I guess the answer is that NSTextView is just totally incapable of having its frame rotated without triggering multiple bugs (especially on older versions of OS X). If that's the case, and NSTextView isn't intended to be used that way, Apple's docs should probably say so. Can anyone confirm that that is the case?

Create an omnidirectional scrollview

I want to create an omnidirectional scrollview that works pretty much like the one in the "Wall of Sound" app. As in, the user should be able to pull into any direction and never get to an end. I want to keep the move to be smooth (and not see the pages change as you would in a standard scrollview). Does anyone know how that can be done? Or would I need OpenGL for that?
Create a 3x3 grid of views, each the size of the viewport. As the scrollview moves into another section, rearrange the views to constantly put the viewport in the center. In most cases 3x3 is sufficient, but if redrawing the views is expensive, you may want to use a larger grid (5x5 for instance). This requires that you have some mechanism for splitting up your full view into tiles.
You can implement the same thing using CALayer if you like. If you go that way, you should consider instead using CATiledLayer. See Matt Long's quick introduction on CIMGF.

maskToBounds:YES affecting scroll performance

I have several UIButtons on a UIScrollView. I want the buttons to have rounded corners, so I call maskToBounds: on each of them. When I do this and run on the device, the scrolling framerate is pretty bad (it works fine on the simulator). Any ideas on a workaround for this problem?
You're causing the view to be composited offscreen with that call to masksToBounds:, which slows things down quite a bit. Are you rendering custom button images? If so use UIImage -stretchableImageWithLeftCapWidth:topCapHeight: with an image which is the minimum width to encompass it's rounded edges. This allows the GPU to handle stretching the image in the most efficient way possible, while still giving you a button made out of an image. There is a session in the WWDC 2011 videos on Drawing in UIKit - watch that, as it addresses exactly this problem, and a few others you're likely to have.
A few alternative methods:
Tweeties implementation of fast scrolling, by drawing everything manually
Matt Gallaghers implementation of custom drawing. This is the method I use, as it's easy to maintain

Image Sequencer using CoreAnimation

I have a list of images (say 180 images of sequence) to animate. If I use UIImageView with its default image sequence, I get memory issue.
I wanted to use CoreAnimation API, but really don't know how to do it?
What is the best way to do this.
Regards
iWasRobot :P
There's a very hard to google example on how to perform view transitions with Animation, here it is:
http://developer.apple.com/library/ios/#samplecode/ViewTransitions/Introduction/Intro.html
Here you would need as little as 2 views. You would load images into the hidden view, then "transition" it in. Assuming your slideshow mode is long enough, you should have no issues with loading times.
Another thing that comes to mind is paging with UIScrollView. Here you would need as little as 3 views
http://ykyuen.wordpress.com/2010/05/22/iphone-uiscrollview-with-paging-example/
I hope this helps!

Why does Adding Core Animation slow down drawing of my NSTableView?

I have a simple App that displays a list of items using NSTableView. There are usually about 15-25 items in the list, and the table has 10 columns, all but one of which are text (the other's an icon.) There are simple data transformers on a couple of the columns. So nothing taxing; you'd expect it to run just fine.
And as it stands, it is; the app is responsive and everything draws pretty much instantly. Scrolling, changing column sizes, resizing the window; whatever you do the redraws keep up with the mouse-pointer.
Tonight, I thought I'd try adding a little visual flair to the app with Core Animation (which I've never used before,) but I've found that if anything above the NSTableView in the hierarchy is set 'Wants Core Animation Layer,' then the NSTableView redraws go to hell. Scrolling is usually fine, but resizing columns or the window causes it to pick up an effect like texture tearing, where some of the rows have the new size, and some have the old one, and everything flickers horribly. It looks terrible. Basically it looks like what you'd expect if rendering the individual rows or columns was taking a long time.
I've put it through Shark and, sure enough, it looks like it's spending most of its time drawing the text in the cells; what I don't understand is why that should take longer when there's a Core Animation layer involved than when there isn't - and quite noticeably longer at that.
Has anyone got any ideas? Is there any Core Animation initialisation or config I've missed or something (I've literally just ticked the "Wants Core Animation Layer" box in IB)?
Cheers,
Will