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: Graham Cox <email@hidden>
- Date: Wed, 11 Mar 2009 11:28:30 +1100
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