[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-debug-dev] 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
