I've modified what I can, to remove the second buffer completely. It's
a little slower now, but I'll have to see how it fares on the slower
devices.
I think I'm fine though with the two buffer approach on a low-res color
device, as it's only going to be using 51k or so for the two low-res
color buffers.
Now in my hi-res version I'm using under 256k dynamic heap memory. Do
you think that is fine then?
(I know that my Treo 650 seems to have way more available than the
Tungsten E. Many thanks goes out to Palm for keeping this stuff
standard :( )
userforgroups@[EMAIL PROTECTED]
wrote:
> Thanks for the info Logan. Here's basically my problem. My dynamic
> heap usage is fairly small, somewhere around 50k or so. The real issue
> is the creation of my two window buffers. Of course on a hi-res device
> (320x320) each is 204k, so there goes a huge heap of heap :)
>
> The reason I do this, is that there is a complex background that I like
> to keep in a "clean" state at all times, thus one of the buffers. Then
> I draw what I need when I need it to the second buffer. When something
> drastic changes and I need to redraw the whole thing, I just transfer
> the buffer from the first "clean" image to the other buffer, then add
> my other "dynamic" elements. Now I could just keep the other as a
> bitmap resource and do a regular windrawbitmap to the one buffer, but I
> have a second requirement.
>
> I might only be updating or clearing a small area at a time during
> normal operation. Small areas, maybe 20x20 pixels, and in order to
> clear them I basically do a wincopyrectangle from the orginal "clean"
> image, to the area I need to clear. So this is why I needed the second
> buffer.
>
> Now, is there someone on the web I can find a list of Palm devices and
> their respective factory heap sizes?
> I see I have two options, forego the second buffer, and when I need to
> update only a small space as I do all the time, just redraw the whole
> darn thing over again, just to "clear" the one area. I could then just
> use one buffer. But this would be slow. Or, I could make a bunch of
> resource elements for all of the grid areas that I need to update.
> Or,I could check the heap size at runtime, and if enough, just do as
> usual, if not, do the one buffer trick.
>
> Any ideas?
> (By the way, I also do Pocket PC and Smartphone development, the palm
> reminds me of Dos days with 640k limits)
>
> Logan Shaw wrote:
> > userforgroups@[EMAIL PROTECTED]
wrote:
> > > I was using my Tungsten E simulator, and noticed that it has a 512k
> > > heap setting already set when you download and run th esimulator. Is
> > > that what is really is?
> > > Here's the reason I ask. I noticed that my program I'm developing
> > > crashes when running, and after stepping through it, I noticed that
a
> > > few of my memptrnew's were returning Null, so of course no more
memory.
> > > Now, I do create two offscreen buffers (hi-res), so I know I eat
> > > through the memory prettyq uickly. Here's the deal...I ran
> > > MemHeapFreeBytes(???) I think that is the name, and chose heap id's
of
> > > 0, 1, and 2. Well, heap 0 is the one that I seem to be alllocating
> > > memory from either by creating my offscreen buffer, or by using
> > > memptrnew's.
> > > But, when I looked at heap id 2, it had over 2 megabytes free (in
the
> > > simulator), and just wondering if I can go ahead and use that if I
> > > want.
> >
> > I think you can use heap #2 for dynamic memory on that device if
> > MemHeapDynamic(2) is true on that device.
> >
> > If I understand correctly, on all devices after OS 2.0 (or 3.0?),
> > there is only one dynamic heap on each device.
> >
> > It's possible that heap #2 on that device is your storage heap.
> > If so, you can't use it because the system write-protects that
> > memory. (That way, a crash doesn't overwrite Datebook entries
> > or something.)
> >
> > Anyway, it's sort of a moot point because it's unwise to write
> > software for the Palm that relies on there being more than 512K
> > of space available anyway. If you need that much space, you should
> > look at storing some of your data in the storage heap either by
> > putting it into a database or by using a feature pointer. In
> > either case, you'll need to use DmWrite() to write to the memory
> > since, as I said, it is normally read-only memory.
> >
> > - Logan
|
