[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-dd-dev] Re: Memory View IMemoryBlock/Extension scrolling
|
Hi -
There is no documentation about how scrolling works in the table
renderings. But I can give you a brief overview of how I solved some the
problems.
Scrolling and Getting Memory Automatically in Table Rendering
=======================================================
When the table rendering is created, the rendering looks at the size of the
view and guess how many lines of memory the view will need to fill up the
view. In addition to what's being shown in the view, the rendering will
create a buffer above and below the view. It will get 20 lines above the
start address of where it's supposed to show and will get 20 additional
lines after the end of the view. So, initially, the view will get <number
of lines required to fill the view> +40 lines of memory from the memory
block. In this case, when the user scrolls within this range, the
rendering will not ask the model for memory again.
As scrolling happens, the rendering figures out if the scrolling has caused
the view to show content at the end of its buffer. When the buffer is
exhausted, the rendering then asks for memory from the model again.
Resizing the View
================
When the view is resized, the rendering will not try to figure out if it
has enough memory to fill the view. This is because the rendering will get
many resize events from the platform. If the rendering is to handle every
resize event, the rendering may load memory from the model many times when
the view is being resized. This is not desirable because communication to
the model could be slow and we need to avoid unnecessary interactions with
the model.
Instead of handling a resize event, the table rendering tracks widget
selection events. When the user clicks on the rendering again, either
clicking in the table or scroll bar, the rendering gets a widget selection
event. At this time, the rendering determines if the view currently has
enough memory to fill the view and will load more memory as required.
So when the view is being resized, the rendering does nothing. At the end
of the resize, the view may not have enough memory to fill the view and
could be showing the end of its buffer. However, when the user selects the
rendering again, the rendering determines if memory is needed based on its
new view size. This will cause the rendering to fill its view with a bit
of delay after the view is resized. But I feel that this is a more
economical solution than handling the actual resize events.
Calculating Changes in Memory
===========================
The table rendering does not calculate changes for the entire memory block.
The table rendering will only calculate changes for memory that is in its
buffer. When the user has scrolled outside of that buffer range, the table
rendering will show those memory in grey, indicating that the view does not
have history for those bytes and as a result, the view is not able to
determine changes. (MemoryByte#isHistoryKnown() reported false.) Models
have an option of managing its own changes. If the memory block returns
true from IMemoryBlockExtension#supportsChangeManagement, the rendering
will not cache and calculate changes for its model. The burden of
calculating changes lies in the model in this case. The rendering will
simply show changes as indicated by the MemoryByte attributes.
I hope this answers some of your questions. Let me know if you need more
information. Thanks...
Samantha
"Williams, Ted"
<ted.williams@win
driver.com> To
<dsdp-dd-dev@xxxxxxxxxxx>,
02/03/2006 04:07 <platform-debug-dev@xxxxxxxxxxx>,
PM Samantha Chan/Toronto/IBM@IBMCA,
Darin Wright/Ottawa/IBM@IBMCA
cc
Subject
Memory View IMemoryBlock/Extension
scrolling
hi all,
I've been working on a rendering for the new memory view and I'm a bit
concerned that I don't have an accurate understanding of how scrolling is
intended to work. Is this covered by a design document? Is there more
documentation than the code itself?
Target connections can be slow. It's therefore essential that the rendering
only reads the minimum amount of bytes necessary to fill the viewport. How
can the IMemoryBlock be sized appropriately? At instantiation time
(IMemoryBlockRetrieval/Extension) a guess can be made, but this is hardly a
solution since the user may resize or reformat the rendering.
IMemoryBlockExtension provides getBytesFromAddress(address, units) for
arbitrary reads. If reading outside of the range of the memoryblock is the
answer, this puts a caching/delta burden on the memoryblock. Is the
memoryblock to keep track of all arbitrary reads so that it can generate
deltas? Or should it simply return MemoryByte[]s with isHistoryKnown()
equal to false and force the view to perform the change tracking work? I
was hoping to find either a IMemoryBlock/Extension.setLength(int) (since we
already have a corresponding getLength()) or a length parameter added to
IMemoryBlockExtension.setBaseAddress(address).
I thought about doing something like the following in response to a user
request to scroll by one row.
myIMemoryBlockExtension = ((IMemoryBlockRetrievalExtension)
myIMemoryBlockExtension.getMemoryBlockRetrieval())
.getExtendedMemoryBlock(currentStartAddressPlusX,
myIMemoryBlockExtension);
This would allow for an elegant reuse of much of the previously read (and
still valid) memory. Of course, it's also embarrassingly hackful.
Help?
ted
