Hi everyone.
I'm trying to develop mirror video driver for VNC-like aplication.
I've made a "stupid" version that just shares framebuffer into user-
space and provide another buffer to store screen updates (just a
bounding rect of a CLIPOBJ). But such a driver "produces" too much
traffic. It is not much less than while using "blit-and-XOR" approach
(BitBlt from screen, XOR with the previous frame and send the result
over a wire) in most cases.
So, I decided to implement a kind of updates z-Buffer, so that you can
discard previous update if it was covered by another one the next
moment. But it is not the case in point.
The second way of bandwidth utilization improvement is taking screen-
to-screen BitBlts into account. They often happen when scrolling
appears. When screen-to-screen BitBlt occurs we need to send just a
notification with the two rects coordinates instead of the whole
bitmap, so this approach can decrease network traffic significally.
But there is one problem. If screen-2-screen BitBlt occurs while user-
mode application reads frame buffer, data sent to the other client
might be inconsistent. And this inconsistency won't be fixed when
"screen-to-screen" command is sent because this command carries no
bitmap data, and data on the other side of the wire is taken from it's
local screen copy which is corrupted.
I see two ways of resolving this problem. First is to refuse the idea
of taking screen-to-screen BitBlt into account and treat them as a
bitmap-to-screen. The second way is to refuse the idea of grabbing the
image directly from the framebuffer and create a separate bitmap for
each BitBlt and share it's bits into userspace. Please tell me what
approach is preferable. I tried to figure it out by disassembling
Microsoft's rdpdd.dll, but it's to complex and has many obscure things
like additional parameters cheks in DrvXxx berfore calling the
corresponding EngXxx and use of private data structures.