[dsdp-dd-dev] RE: Memory View IMemoryBlock/Extension scrolling

["Williams, Ted" <ted.williams@xxxxxxxxxxxxx>]

> I hope this answers some of your questions.  Let me know 
> if you need more information.  Thanks...
> Samantha

It confirms my basic understanding of how the table rendering works.
Thank you.

Do you have any additional thoughts on how you would implement scrolling
and data reading with the intention of never reading more than the
amount of data required to populate the viewport? 

This is what I see happening with the hex rendering:

-> Create new hex rendering at a memory address.

getExtendedMemoryBlock(address, ...)
getBytesFromAddress(address, 656)  // 656 bytes
getBytesFromAddress(address, 448)

The view (by default, without any resizing) is displaying 9 rows, 4
columns wide, with 32bits of data per cell. To fill the viewport, we
need 144 bytes of data from the model. The first read requests 656
bytes. Over a slow target connection, this seems excessive. More than
four times the viewport data is read. Immediately following the first
read comes a second request for 448 bytes. Is this expected? 

-> Scroll view to the bottom so that view refreshes buffer.

getBytesFromAddress(address, 752)

-> Scroll view to bottom again. View loads more data.

getBytesFromAddress(address + 0x120, 768)

Since suspend events invalidate the entire buffer, the value of reading
a larger buffer is in improved scrolling and memory-changed status,
right? Shouldn't this at least be user configurable? When stepping with
the memory view open, I expect the view to present real time (not stale)
data, but without the expense of over reading.

Thoughts?

ted