you are returned an array of images, and then you'd call destroy on them, yes.
On Thu, Jul 23, 2009 at 4:35 PM, Ryan Florence <[email protected]> wrote: > Great info. Thank you. > > If I were to load an image with Asset.images, how would I "retire" it? > destroy()? > > On Jul 23, 2009, at 4:35 PM, Aaron Newton wrote: > > I think you could push the limits of what the browser and the user's CPU is > capable of in a responsive manner. It's far better to load, say, the first > page of "hair" and then, if they click on the next page, to fetch the next > page and merge the data with the first group (or have an array of hair page > data or something). Using up memory this way isn't too big of a deal given > that most computers these days have at least a few hundred MB of RAM (and > most over a GB). But processing thousands of records on startup will produce > a noticeable lag. > As for assets.images, here you must be more careful. You should "retire" > content when it moves to far away from the view. For instance, say you load > the first page of hair and display it. You might also load the 2nd page so > that moving to page 2 is super fast. But if the user navigates to page 9, > you don't want to keep page 1 and 2 around. You need to expire things > smartly to keep memory usage down (esp if there are thousands of items). > > -aaron > > On Thu, Jul 23, 2009 at 3:00 PM, Ryan Florence <[email protected]>wrote: > >> >> So I've got a site that's got something along the lines of the Mii >> creation tool on the Wii. There's a stage where the user adds images by >> category (hat, hair, glasses, etc.) and moves them around to wherever they >> like. >> >> At the moment I'm bringing in each category via Request.HTML and then just >> updating the div that displays all the different items (like hair styles). >> Each element (or hair style) had it's database info in an attribute of the >> element. >> >> We had this discussion a few days ago, and it's got me thinking. So I was >> switching the request to Request.JSON and then drawing the elements out via >> javascript (instead of echoing it out in PHP via Request.HTML). Then I had >> all my data in an object and didn't have to worry about using an attribute >> on the element. >> >> Then I thought, "Why not just load the entire database of items into an >> object, then just deal with it all client side?" >> >> Our plan is to eventually have thousands and thousands of items, that's >> why I went with request so that I didn't have to load them all in unless the >> user selected the category. >> >> I'm entirely tempted to use Asset.Images in accordance with a big fat >> object that contains all my database instead. Is there ever a concern of how >> big the object will be? It's certainly going to be less space the images it >> loads. >> >> -Ryan >> > > >
