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.
It seems like you could solve this problem without having a background
buffer.
You should be able to take a bitmap that is in a resource, lock the
resource, and use WinCreateBitmapWindow() to make a window wrapper
around it. Then you should be able to use WinCopyRectangle() to copy
parts of it to your buffer that you use to update all or part of the
screen.
There are probably some gotchas with this approach. One is that you
don't want to make the bitmap resource compressed, because that will
slow down copying. Another is that resources cannot be bigger than
64K, so you will have to break the original into tiles (or bands),
which makes copying it to your screen update buffer more complicated.
The last is that you really want your bitmap to have the same depth
as the screen, so that could be a little tricky. But, it should be
possible, with care, to overcome all these problems.
A different approach is to just allocate some memory in the storage
heap. This memory can't be written to in the normal manner, and
you must use DmWrite() to write to it, but you can read from it just
like any other memory (it is addressable). So, you could do some
sequence like this:
(1) Start your app.
(2) Allocate one big buffer in dynamic heap.
(3) Build your background in that buffer.
(4) Allocate memory from the storage heap using a feature pointer
(FtrPtrNew()).
(5) Copy the background into the feature memory with DmWrite().
(6) Re-purpose your big buffer (in dynamic heap) as a display-update
buffer.
Just how much memory is available in the storage heap depends on
what the user has installed (since PRCs and PDBs go there), but
on a blank device, there is always more space in the storage heap
than the dynamic heap.
And, by the way, I agree that these limitations are kinda crazy. But,
considering that the original device had only 128K, they're not that
surprising...
- Logan
|
