Mostly just a question - is this normal behavior on the VNC? monitoring my memory usage, I’ve found on every frame request that it’s allocating an entire frame buffer out of the heap which eats up my ram quickly (VNCHost->WriteFrameBuffer creates a new buffer every time instead of just passing the reference to the FB data) I have a tenuous relationship with GC that is running a blocking call when it gets low enough whcih can cause issues with some things, i’ve found.
Is there a reason for this? Would it cause problems if it was just using writing the buffer directly? This is also for my own edification so if this is intended behavior I’d love to learn why - it just seems like an extra step that adds inefficiency.
I think that the logic in VNC (aside from its use in TinyCLR) is that one does not want to interrupt the video swap chain rhythm. Using the framebuffer directly would mean you would have to pause updates to the framebuffer, and that would ruin local animations or cause periodic unresponsiveness of the UX. A mem-to-mem copy to something outside of the live framebuffer can happen fast enough to avoid stutter and happen at the end of a swap or update (when you know you have a fully updated frame).
Once you accept that you need a backing store for the framebuffer, then the only two options are static allocation or allocate-as-needed (which has the advantage of letting you use that memory between VNC frames). Both are going to increase the probability of a GC being needed.
I think this is a necessary evil of having VNC without causing unresponsiveness or stutter in the user experience.
We are thinking not allocate every frame.
I think now TinyCLR has enough api that support any size without allocate memory every time. We will improve in next version.
I mean, that makes sense, but how come you couldn’t do the same thing with a static secondary buffer that is created upon connection (Dat brought up if differing screen sizes)? that way when the frame buffer is generated by the graphics object, it can be copied into that second buffer that is manipulated by the network? I’m not questioning the use of a second framebuffer (this would especially make sense on a true multithreaded system to keep it thread safe), more just confused that this buffer is completely regenerated every frame. If i was running my VNC at 10 FPS i would eat up my available ram in 3 seconds. I may be wrong, but In my mind it would make more sense to use a single buffer that gets created when the VNC session is negotiated with the viewer.
10 FPS may be out of the realm of feasibility for such a small system, the fact that VNC works at all on these chips is pretty cool, but I just wanted to be sure I wasn’t missing an obvious reason why it was done this way.