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
