Prevent NSOutlineView (or NSTableView) from redrawing on scroll - objective-c

It seems that my view-based OutlineView try to re-render text every time user scrolling. I think that was because it tried to save memory by re-using rows that fall outside of visible rectangle, then re-render new data to those old views. How can I disable this? I'm willing to sacrifice memory to archive this so that I can get better scrolling performance. (I have tried with various optimize like layer or so, but no luck).
EDIT: There is another question with same purpose as mine here How to make NSTableView not reuse TableCellViews, but no answer yet :(

I think you are confused -- it doesn't re-render the text. The table only shows views for the visible area (caveat below), and pulls in new views as you scroll -- potentially re-using old views.
You provide the view. Use the delegate method viewForTableColumn:row: and return your own cached view for a given row.
But that isn't going to prevent drawing; the view will likely still get marked dirty and draw.
I don't think you are asking the right question. It sounds like you have a performance problem. To help you with that, we'd have to see samples or instrument traces.
Caveat: Responsive Scrolling will pull in views that are in the non visible area. See the AppKit release notes about this.
corbin

Related

Recreating the whole UICollectionView vs invalidating the UICollectionView layout on an orientation change

I have a horrible problem that is worthy of a separate stackoverflow question. Perhaps I can save time by asking a different question:
What are the downsides to recreating the whole UICollectionView layout on every device rotation rather than invalidating the UICollectionView layout with invalidateLayout?
Bare in mind that its a small view with a maximum of 6 text based cells - not a lot of data.
This question is a follow on from this one. I implemented the UICollection view and everything is working except the first two buttons inside the cells aren’t changing width on a orientation change, its a mess. Its almost like the method to update the cells is definitely being called but with the data from the last orientation view. Even after lots of debugging I'm still unsure exactly what the problem is.
Update
I managed to solve my nightmare with the information from this answer and the actual code from this answer. But if someone can still answer this question it would be helpful and interesting, I still want to know the answer!

How can I fix the flicker occurring when selecting an NSCollectionViewItem?

I've got an NSCollectionView which houses three columns of NSCollectionViewItems. In each of the NSCollectionViewItem prototype views, I have a single NSImageView. As far as I'm aware, this is a fairly standard setup. I think the problem stems from my use of a popover to present the collection view, but I'm honestly not sure. Basically, the problem I'm having is that when I click on one of the aforementioned NSCollectionViewItems to mark it as "selected," every once in awhile it flickers/flashes. It's not a total deal-breaker, but it's annoying enough to make me post this question.
Coming from the HTML/CSS/JS game, I started to think of all the ways I would prevent the flicker when building stuff with web technologies. My first thought was to make certain parts of the NSCollectionView (and subviews) layer-backed. I figured that by doing the drawing via layers or just setting the collection view to be layer-backed period, it would render better, kind of like GPU-enhanced animations in CSS (e.g. no sub-pixel antialiasing, enables z-depth, etc.).
So, I subclassed NSCollectionView and added a [self setWantsLayer:YES] in the
-(id)initWithCoder:aDecoder method. I was right! It removed the flickering altogether. Also, the scrolling became much smoother. However, in the process of making the flicker go away, everything else started messing up. The popover would take about 10s to load (vs. ~500ms originally), items would do weird overlapping things, etc.
My question to you all is this: what should I do? If anyone could help a brother out, I'd really appreciate it.

Extended NSTableView

I would like to make a table-view with expanding ability.
When you press a row, the row should expand to show options like delete, copy and so on.
I have found an example for iOS, but I didn't get it running on Mac OS X, because NSTableView and UITableView are very different.
http://www.cocoacontrols.com/platforms/ios/controls/kofiles
Has anyone another template?
Or maybe even get this example running on Mac OS X?
I don't have code to hand you but you can use a view-based NSTableView. Your prototype view can resize itself to include controls if it's selected. All that's a bit complex to condense into a reasonably brief answer but if you use a view-based table view and treat the prototype view like any other that would grow and show extra controls, then wire this behavior to the selection state, it should work.
Note: you will have to write some code for the expansion portion, to handle resizing it, showing the controls, and notifying the table view that one of its rows changed height. Lots of documentation and examples exist out there for each individual component of your problem. Post more specific questions as you run into roadblocks.

Lazy loading images in a UITableView that has a scroll index

I think this is a new spin on an old question, but I'm completely stuck here.
In my app, I have a UITableView with 650 cells, each with a custom 16x16 RGB icon. On most recent iOS devices, loading all of those icons into memory before displaying the table works totally fine, but on older hardware, I'd like to implement a lazy load system that only loads icons it needs.
I've implemented the Apple LazyTableImages example, (which uses a UIScrollView delegate to determine when the table stops moving to load the visible icons), but I've run into another snag.
My UITableView also has a section index display (ie the list of labels on the right hand side you can swipe up and down to scroll quickly), and the LazyTableImages example hasn't taken this into account.
If I scroll using the index, the images won't lazy-load. :(
As far as I can see, the scroll index doesn't actually have any delegate events it triggers.
So I'm wondering, has anyone else tried to implement lazy-loading on a table with a scroll index? Is there any way to track the index and find out if the user has interacted with it?
Thanks!
After buzzing around a few of my iOS developer buddies, I came up with a solution that worked well enough.
I set it up so that in addition to the icons being loaded from the UIScrollView delegates, an NSTimer object will periodically call a method that checks the currently visible table cells ([UITableView indexPathsForVisibleRows]) every .5 seconds, and loads any icons on the screen that haven't been loaded yet in a single separate thread.
I tried to make the solution as efficient as possible, so I made sure the timer was only active when the tableView was visible and stationary, and I liked it since it meant that every visible icon regardless was addressed.
One thing I discovered was that if the tableView was reloaded while the thread was looping through the visible cells (rare, but was possible), it would crash. The solution to this was to make sure each cell data source entry was retained while the icon was being loaded.

Customising UITableView scrolling!

Is it possible to make the table view allow scrolling only in one section and not others OR in other words allowing scrolling only in desired sections of the grouped table?
Many thanks.
Sure, this is entirely possible if you're willing to forego the use of a tableview. If you use a scrollview, you can achieve what you want by defining custom behaviour. It's not going to be easy but here are some suggestions:
Figure out how you want it laid out on the screen
Create a "floating cell" that will hang around, this will be your "not scrolling" section
With respect to #2 above, you'll have to figure out what kind of logic you want to make that floating cell disappear versus the other data.
The rest, you're effectively reimplementing a tableview.
Now, you can probably achieve this with a tableview, but it's be hairy big time.