I have a large data set (some 3500 objects) that returns from a remote server via HTTP. Currently the data is being presented in an NSCollectionView. One aspect of the data is a path pack to the server for a small image that represents the data (think thumbnail for simplicity).
Bindings works fantastically for the data that is already returned, and binding the image via a valueurl binding is easy to do. However, the user interface is very sluggish when scrolling through the data set - which makes me think that the NSCollectionView is retrieving all the image data instead of just the image data used to display the currently viewable images.
I was under the impression that Cocoa controls were smart enough to only retrieve data for the information that is actually being output to the user interface through lazy loading. This certainly seems to be the case with NSTableView - but I could be misguided on this thought.
Should valueurl binding act lazily and, moreover, should it act lazily in an NSCollectionView?
I could create a caching mechanism (in fact I already have such a thing in place for another application - see my post here if you are interested Populating NSImage with data from an asynchronous NSURLConnection) but I really don't want to go this route if I don't have to for this specific implementation as the user could potentially change data sets often and may only want small sub-sets of the data.
Any suggested approaches?
Thanks!
Update
After some more testing it seems that the problem arises because a scroll action through the data set causes each image to be requested from the server. Once all the images have been passed over in the data set the response is very fast.
So question... is there any way of turning off the valueurl fetch while scrolling and turning it back on when scrolling has finished?
My solution is to use a custom caching mechanism like the one I already use for another application. The problem manifests itself because as you scroll past images that have not yet been downloaded, the control triggers itself to go and fetch the as yet non-downloaded files.
Once downloaded the images are available locally and therefore scrolling speed normalizes. The solution is to check to see if the image is available locally and present an alternate app-bundle graphic while the image is being downloaded in the background. Once the image has been downloaded, update the model with the image replacing the stub image that came from the bundle.
This leaves the UI in a very responsive state throughout, leaves the user with the ability to interact and allows for a custom background management of the images.
Of course it would have been nice if Cocoa id all this for me, but then what would I be left to do? :-)
Related
In relation to How to determine if a user has scrolled to the end of an NSTableView
Thanks Josh.
Is there a way to use this mechanism to implement a NSTableView that provides some sort of infinite scroll or pagination.
The idea is to tell NSTableView to load up to a certain number of records, say 1k records at once and than as user scrolls closer to the end pull another 1k records and maybe forget the first 1k records.
This pattern is well defined/used in web applications and java. Only the visible number of rows is loaded initially and the rest is pulled async as user scrolls up and down the table.
I am interested in some obj-c code or tips on how to code this.
I know about filtering/limiting the number of records that go into the tableview but lets ignore that for a moment.
Thanks.
Given the details you've provided, I'll generalize a bit but here's how I might solve it:
First, I'd set a MUCH SMALLER batch size than 1000 records. If the result count or "the most anybody is ever going to want to see" is indeterminate (and it sounds like it is in your case), the user probably doesn't even care past the first 100 or so. If your user often requests a large, expensive list and immediately wants to see stuff so far away from the beginning they hurl the scroller downward for two minutes straight before they stop and look around, perhaps a more intuitive sort order is needed instead of asking Google Image for 1000 more animated kitten gifs. ;-)
The controller behind the (definitely view-based for view reuse) table view will need some sort of request queue since I assume you're batching things in because they're expensive to retrieve individually. This will manage the asynchronous requesting/okay-now-it's-loaded machinery (I know that's vague but more detail is needed to get more specific). You'll make sure any "currently alive" views will somehow get this "it's ready" notification and will go from some "busy" UI state to displaying the ready item (since we NEVER want to keep the table waiting for a ready-to-display view for the object at a given row, so the view should at least show some "still waiting for details" indication so quick scrolls over lots of rows won't stall anything).
Using a view-based NSTableView and associated data source methods will let the table view handle only keeping enough copies of your custom NSTableCellView around to reuse during scrolling. Since you have to provide a configured view when asked, the view's default state can either be "draw nothing if not ready" or some visually generic placeholder until the object is realized and ready (then you can just reload that row instead of the whole table). This way the table keeps scrolling and drawing rapidly because it doesn't care about what your controller is doing to fulfill the promise of updating the visible rows (that custom cell view of yours will observe its represented object's updates).
You probably want the scrollers to reflect the total number of rows batched in so far if the upper bound is astronomical - reflecting that size would make the scroll grip both tiny and very sensitive. Instead, just grow the scroller (via the table view's row count) by what the user has "requested" so far, all the way back to the beginning of the list. Any time more are batched in, you'll want to add the batch size to your controller's total batched row count. This still lets the scroller zoom by rows the user couldn't distinguish at that speed anyway. You communicate the row count change to the table view by sending it -noteNumberOfRowsChanged and replying to its resulting data source request ( -numberOfRowsInTableView: ) with the updated total row count you stashed in a property of your controller. It'll ask for views for the newly visible rows as needed (which will be in some neutral, unfulfilled visual state until it's realized as before), update the scroll view, lather, rinse, repeat.
You could use NSCache to keep memory usage low. Set its countLimit to several times your batch size and let it drop previous batches if it decides it needs to dump the first n model objects, then batch them back in if the table view suddenly asks for a view for a row no longer in the batch window's range.
Without knowing more about your requirements and architecture, it's hard to get more specific. If I haven't hit the mark, consider editing your question to include more detail. If I'm totally off base from what you're asking for, please clarify. :-)
I know more about iOS, but I think the answer is similar. Table views are intrinsically finite, but you can roll your own custom scroll view to do this. The trick is to set a large content size and implement layout in your subclass (which will get called on every scroll change). In that method, check to see if the content offset is near zero or near the content size. If it is, then translate the content offset back to the center of the content size and translate all the subviews (keep them on one parent content view) by the same distance so the user doesn't see any motion. Make a datasource protocol and keep asking your datasource for "cells" that tile the visible part of the view.
It should be up to the datasource to recognize what we would have called a page-fault in the olden days, to decide that some of the model in memory should be discarded in favor of the model where the user is scrolling.
I poked around for an NS equivalent, but didn't see one on cursory search. Here's a decent-looking reference on the idea done in iOS.
I have already sort of asked this question already here (Previous Question) but it only got a handful of views and zero answers/comments so I thought I'd give it a go again with some more info that I've found.
I basically have a Windows Store DirectX + XAML app that I'm developing. I currently have the problem that the Rendering event of the SwapChainBackgroundPanel that I use for DirectX rendering (as per the Windows 8 example on MSDN) sometimes isn't called when the user is interacting with the app.
It will continue to update if I am doing something with the camera such as changing what it's looking at based on touch/mouse position but it won't be called if I am picking and I don't know why.
I use the standard GPU picking method (where I render the scene with a unique color for each object and then take a 1x1 texture of the press area to find the selected object) but when I am using this picking technique to select multiple objects (the user drags their finger/mouse over many objects) Rendering isn't being called. So in effect what happens is, lots of objects get selected but the user only sees this when they remove their finger/stop pressing the mouse button.
Is there any reason why this is happening? Is it because of the GPU picking method? And if so is there a way around it rather than using the ray-trace picking method (which considerably slows down picking for a large number of objects)?
Has anyone else had this problem? Is there an explanation from Microsoft anywhere that it is deliberate that rendering doesn't get called while this is happening?
Thanks for your time.
I am rendering using SlimDX to a control in a form. Since the size of that control might change very often, and there are lots of complex meshes, the traditional free-reset-construct method may be too slow to my taste. Any way to boost it up?
create an additional SwapChain linked to your current window using IDirect3DDevice9::CreateAdditionalSwapChain Method,
then, get the back buffer of the new SwapChain, and, use IDirect3DDevice9::SetRenderTarget method
to set the back buffer of the new SwapChain as the render target,
when you finished your drawings, call the present method of the new SwapChain instead of the IDirect3DDevice9::present,
when your window is resized, just release the additional SwapChain and re-create it with new back buffer sizes and do the render target setting thing again, now, you don`t have to do the device reset which is very slow.
if you have any more questions, email me : xux660#hotmail.com
I am a chinese so my english is not so good, forgive me.
I'm trying to create a menu for a local multi-player game that dynamically updates when peers become available on the network.
The interface I want to implement is a UIScrollView, where each page displays information about a peer. Ideally, these pages are added and removed when a peer's availability changes.
I have looked through several tutorials using UIScrollView, but they all seem to pull page information from a plist or pre-loaded array.
What I want must be possible; weather app behaves in a similar manner, dynamically adding or deleting location pages. I'm not sure where to turn for further help, though. How do I dynamically update my scroll view's contents as outside events occur?
I decided to go with UICollectionView instead, it seems to provide a better method of implementation for what I'm trying to accomplish. Thanks!
Have a look at this Ray Wenderlich Tutorial.
I've used it as a basis for doing a paged scroll and the mechanism is simple enough to extend to whatever dynamic scheme you would like.
You can check this site for Multiple Tutorials & examples for UIScrollview. The link:
is Here..
I am sure, you'll able to find some good code for your need. Hope it works for you.
I am implementing a UITableView with two images in a cell. Both images will be obtained via URL. I was wondering what is the best approach to load both these images asynchronously.
There were a couple of recommendations:
http://www.hollance.com/2011/03/mhlazytableimages-efficiently-load-images-for-large-tables/
and
http://www.markj.net/iphone-asynchronous-table-image/
However, I am not very sure which is the best approach for my requirements
1) Loading of around two hundred cells in a UITableView
2) Each cell contains two images to be obtained via URL
Those links should be useful. One good thing about UITableViews is that they do not create all of the cells at once. This means that if the images start loading only when applicable cells are created, it'll roughly load the ones on the screen first, which is a desirable behavior. If you make sure that the images are only retained by the UIImageViews then you won't risk having all images cached in memory in a low memory situation, as cells can be recreated. Depending on what kind of data you are loading, you may wish to cache the images – sized to their target dimensions – in the filesystem or database.