In article <b1c9e2ae.0408282208.8fa00a4 DeleteThis @posting.google.com>,
micjuneau DeleteThis @gmail.com (Micjuneau) wrote:
> So you're saying:
>
> 1) ditch the NewHandle line (when *must* I use NewHandle?)
Yes. The resource manager will continue to own the handle.
> 2) put myPicH = NULL; before loading it up to have a guaranteed false
> result if things do not load correctly
Yes
> 3) remove the DisposeHandle line.
Yes
> 4) Assume that the mac's kernel will handle everything about handles
> itself through GetPicture? So in a sense, I wasn't taking advantage of
> what seems to be a hassle-free, autonomous environment concerning
> handles? What if I'm memory constrained, would not caring about the
> fate of a certain number of picture handles bar me from having enough
> memory?
Some handles are resources, owned by the Resource Manager. They aren't
entirely automatic: If they are marked Purgable, the Memory Manager is
allowed to purge them, so correct code would check that they are still
present with NULL != *myPicH, and call LoadResource() if necessary, call
HNoPurge() while it is using them, and call HPurge() when it is done
with them (The advantage over ReleaseResource() is that
ReleaseResource() frees the allocated memory NOW, while HPurge() just
makes it available if the system needs it, so if you re-use a resource,
you might not need to re-read it from disk.
>
>
> >
> > > SetPortBits(loadBM);
> >
> > this stores loadBM into newG, even though you've carefully allocated an
> > appropriate bitMap into newG. You just leaked newPort's original bitMap.
>
> It's true that it's a redundant line. I must have put it when I failed
> to understand everything that I was doing/everything that I figured I
> needed to do. It's true that CreateOffscreenBitmap does associate
> loadBM with newG. Doing it again with that line is overkill. However,
> I don't understand how things "can leak" from doing it twice. I don't
> master the inner workings of memory enough. Care to elaborate?
you did a NewPtr() and assigned it to the baseAddr field of the bitMap
field of newG. Then you made qd.thePort point at newG, then you called
SetPortBits(), which stores over the bitMap field of qd.thePort. Now,
nothing points to the NewPtr()ed block, so nothing can ever call
DisposePtr() on it.
> > Do you know the concept of "ownership"? if A owns B, then only A has the
> > right to destroy B, and A has the responsibility of destroying B when
> > the time comes.
>
> It's a bit daunting for me to plan that kind of thing - I knew I would
> have some struggles about this. What little I know from C++, is that I
> could stop all that intertwined function calling labyrinth with some
> classes.
C++ gives you tools, destructors that are guaranteed to be called for
each fully contructed object, and like boost::shared_ptr, or
PowerPlant's StDeleter, but it is still up to you to think the issue of
ownership through. Languages like C# and Java have integrated garbage
collectors that preserve correctness of leaky programs, but leaky
programs will still perform worse than ones that build up garbage.
> > You need to go through your code and think about who owns what when.
>
> Ok, here's the kicker:
>
> When I make the above changes that you gave me about the picHandle,
> everything still works. Only when I remove the "redundant"
> SetPortBits(loadBM), does the graphic become garbled again!! It seems
> it's the one line that actually makes it survive the
> DestroyOffscreenthingy function. What the who why, now?
You need the SetPortBits(loadBM) so that the graphic will draw on the
port you think it is drawing on. What you still lack is saving and,
after the drawing, restoring the original BitMap of the port, so that
when you dispose the port, the correct bitmap is destroyed. Also, since
that bitmap exists only so you can destroy it, you don't need to go
through the extra work of NewPtr()ing it to the correct size.
Since you asked this question, it seems that you are still not clear on
what data structures own which other data structures.<!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: old school offscreen graphics