[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dsdp-dd-dev] Re: [platform-debug-dev] RE: Memory View IMemoryBlock/Extension scrolling
|
Hi -
Re: reading memory twice:
getExtendedMemoryBlock(address, ...)
getBytesFromAddress(address, 656) // 656 bytes
getBytesFromAddress(address, 448)
I am not able to reproduce here. If you are just creating a single
rendering, then this is not expected. Please file a bug report.
Re: Optimizing how much to read.
Yes, the value of reading a larger buffer is to improve performance at
scrolling and memory-changed status. User cannot configure the pre/post
buffer size. There could be a new user preference to allow the user to
configure this. There is also a preference to turn off the
"auto-scrolling" mode. If you go to the "Table Rendering Preferences", you
can turn off the auto-scrolling mode and define exactly how much memory to
monitor in a table rendering. User can scroll to the next page of memory
via the "Previous Page" and "Next Page" actions.
Alternatively, we can also define the pre and post buffer size based on the
window size. If the window size is bigger, the rendering buffers more
memory. When the window size gets smaller, the rendering buffers less.
For example, we can define a rendering to buffer 25% of the window size.
Thanks...
Samantha
"Williams, Ted"
<ted.williams@win
driver.com> To
Sent by: Samantha Chan/Toronto/IBM@IBMCA
platform-debug-de cc
v-bounces@eclipse Darin Wright/Ottawa/IBM@IBMCA,
.org platform-debug-dev@xxxxxxxxxxx,
dsdp-dd-dev@xxxxxxxxxxx
Subject
02/03/2006 08:38 [platform-debug-dev] RE: Memory
PM View IMemoryBlock/Extension
scrolling
Please respond to
"Eclipse Platform
Debug component
developers list."
> 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
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev