Infinite scrolling

[AngryCarrot789]

I've managed to botch together infinite scrolling by making HexView.CanVerticallyScroll public and setting it to false, adding a handler for HexEditor.EffectiveViewportChanged which creates a new MemoryBinaryDocument with enough memory to fill the viewport (assuming a fixed line height of 14 pixels), and I use a custom OffsetColumn to add an additional offset to the text when the user scrolls up/down (by handling PointerWheelChangedEvent on the hex editor, using RoutingStrategies.Tunnel), to give the visual feedback that scrolling is happening, even though it technically isn't.

When the user actually scrolls, I schedule data to be read from a source, and when the read completes, it updates the document in the background, so when the user scrolls down, initially they will see 0s at the bottom until the background read operation completes. Perhaps it could instead read X amount of lines above and below the viewport?

While it sort of works, it would be nice to see official support added for this, since one problem I have is maintaining the caret position; I have to subtract the scroll offset from it, which works until the caret goes offscreen.

[Washi1337]

What is the usecase for an infinite scrolling document?

Note that IBinaryDocument can be implemented in such a way that it spans the entire 64-bit range without actually having a physical buffer behind it. The control only calls ReadBytes for all lines that are visible in the current viewport. Latest commit should also make it work with documents that have ValidRanges starting at a non-zero offset.

[AngryCarrot789]

My current use case is exploring the contents of RAM of a remote target (via Tcp). My first attempt at making it was to have Base/Length text boxes that the user fills in then reads that chunk, but having used it myself it's not convenient, so instead I'd prefer just a single text box, maybe "Jump to", and let the background reader handle the rest.

[Washi1337]

My current use case is exploring the contents of RAM of a remote target

I am pretty sure this can be implemented with a custom IBinaryDocument implementation with no changes to AvaloniaHex itself today. Also, RAM is not infinite either; on typical machines it will either be a 32-bit or 64-bit range (of which only 48-bits are actually used). You can set the valid ranges property to such a range, and implement IBinaryDocument::ReadBytes method to read from the remote machine based on the range the control requests. The control should then just automatically adjust to your document, and give this sense of 'infinite' scrolling without having a full physical back-buffer on the host machine.

[AngryCarrot789]

I'll try it out, thanks.

[AngryCarrot789]

I can't figure out a way to do it asynchronously. I can't read in ReadBytes because it will block the main thread, so I though maybe I should use a ConcurrentQueue of requests (ValueTuple<ulong, ulong>) and process them in the background then fire Changed on the main thread when completed, however, I'm not really sure how to store the buffer I just read so that ReadBytes (triggered by Changed fired) can access it. Any ideas?

[Washi1337]

Async IO is currently not built-in indeed. There is no easy full solution I can think of right now, Async IO is hard.

However, I can envision a solution that would use some sort of CPU cache-like structure: Essentially, a cache that maps (aligned) addresses to chunks of data previously read from the remote memory. ReadBytes would first check this cache if the requested data was read before and return that. Otherwise, it would push a request onto a Channel and exit early. Simultaneously, a worker thread could continuously read from this channel, handle the incoming requests, update the cache accordingly and push a Changed event when a change was made. If the visual line is still in the view port, the control will then automatically call ReadBytes again with the same offset.

There are some interesting implementation details though (e.g., what happens if only part of the requested data is cached, and how to prevent the cache from growing indefinitely), but this is probably how I would approach it.

[AngryCarrot789]

Yes that's the idea I had. I decided to duplicate most of the original classes but replace IBinaryDocument with IBinarySource, which has ReadAvailableData and RequestDataLater (which fires DataReceived, which invalidates the visual lines). One implementation in my own project is to use a list of fragments (address and byte[]) and to merge/split fragments when writing/clearing data, similar to what BitRangeUnion does I believe. As for preventing the cache growing infinitely, I call InvalidateCache twice relative to VisibleRange when it changes (in AsyncHexView.UpdateVisualLines). Feel free to check it out, maybe there's some ways to improve it. It seems to work nicely so far.

https://github.com/AngryCarrot789/AvaloniaHex/blob/main/src/AvaloniaHex/Async/AsyncHexEditor.cs

(The only implementation I actually use)
https://github.com/AngryCarrot789/MemoryEngine360/blob/master/MemEngine360.BaseFrontEnd/Debugging/ConsoleHexBinarySource.cs