[vbox-dev] Effect of locking the framebuffer in IFramebuffer implementation

[Rūdolfs Bundulis]

Hi,

I wanted to understand what are the consequences of locking the framebuffer
of an IFramebuffer implementation while the machine is running for let's
say ~2ms. I am performing H.264 encoding of the framebuffer data and to
avoid memcpy() I initially lock the critical section that is used in
IFramebuffer::lock() / IFramebuffer::unlock() during RGB32->NV12 color
conversion where I use the framebuffer directly and unlock when it is done.
So this means that any update of the framebuffer from the VM during the
color conversion will block. How does this affect the VM? Since I don't
know the internals I guess if the IFramebuffer is updated direclty (e.g.
every time some application calls BitBlt or anything else) this is bad,
since the whole OS will stall, if it is done in some asynchronous way then
I guess it's not that bad, I'm just getting some extra latency. Can anyone
with the knowledge of the internals give some advice should I stick with
actually doing a memcpy() from the framebuffer (this would decrease the
time period during which the framebuffer is locked) or is blocking the
lock() methods for such amount of time is ok?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140918/a3a3c77c/attachment.html>