Re: What is using up so much memory here?
Re: What is using up so much memory here?
- Subject: Re: What is using up so much memory here?
- From: James Cicenia <email@hidden>
- Date: Tue, 10 Mar 2009 20:13:43 -0500
Yes, I realized I would need a different approach. I got too used to
web gif/png and just doing overlays.
I have already told my designer to give me just bounded states with a
spreadsheet of what he chopped
off from the top and left. This will then be inputted into the
spreadsheet then into sqlite.
It should work a lot better.
Thanks again for your input.
James Cicenia
On Mar 10, 2009, at 7:28 PM, Graham Cox wrote:
On 11/03/2009, at 11:00 AM, James Cicenia wrote:
Well... easier said then done. How would one place irregular shapes
of the state over the map itself?
Any combination of states with a color needs to appear.
Since you are in a much-more memory-constrained environment, you
need to get smart. Naively loading everything isn't going to work,
so you need to figure this out.
You have a map of the USA, I guess, and you can see part of it on
screen at any one time (presumably scrolling to show different
parts, or zooming in and out to show more or less). You can treat it
as a bunch of tiled shapes, each having a bounding box. The bboxes
will overlap a little in many places, but that's OK. All you need to
do is build a data structure that associates the bboxes with the
relevant images and graphics, then determine which bboxes intersect
the visible screen area. For those that don't, you don't need to do
anything. For those that do, you need to load the graphic elements,
scale them as appropriate for your zoom (if need be - zoom is
usually taken care of using the view's scale transform, but you may
want to avoid caching a full-scale image if your zoom suggests you
don't need it) and draw them. When you've done that, you can discard
them again, or cache them for later.
That's the basic M.O. If dynamically loading these images like this
is too slow, you can then consider a way to cache what you loaded in
such a way that when you become memory constrained, you can examine
the cache and discard parts of it that you can't see right now,
again by testing which bboxes intersect the screen.
The same technique will work for zooming, because all you're doing
is making the screen area that intersects your data smaller and
bigger. If you cached a low-resolution graphic for a zoomed-out
view, you can scale it while zooming is in progress to avoid an
expensive re-load, then, if needed, reload a higher-res version at
the end.
Unfortunately you'll have to figure a scheme for doing all of this
out for yourself, there isn't anything built-in because the need to
do this is not all that generalisable. It's not that hard though. I
would suggest though that using an entire subview for each overlaid
image is going to hurt badly in terms of performance, scalability
and ease of implementation. Instead just devise your own data
structure that can hold objects having a bounding box (which sets
the spatial location) and a reference to the image(s) it needs. Then
when you draw, ask your data structure to draw all the cells that
intersect the drawing area. For those that haven't loaded their
images, they should now do so, then draw as usual.
The overall data structure would have one object per state, but all
it needs to maintain when not visible is the bbox. 50 rects is a far
lower memory footprint than 50 full-sized images.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden