[vbox-dev] Synchronizing access to the framebuffer in VirtualBox 5

[Rūdolfs Bundulis]

Hi Vitali,


> the guest may access the guest VRAM between NotifyUpdate calls.
> Which means that in principle the guest can change the content while the
> frontend thread is reading pixels.

Yeah, it seems that this is what is happening. It can be easily observed
when looking at the mouse cursor in our video stream - you can see some
pixels of the previous ones. If there just was something equivalent to the
old
IFramebuffer::Lock() then we could just prevent the guest from accessing
the pixels (I mean it would still be for a very short time - only as long
as it takes for the pixel conversion). I mean my plan Z now is that I can
recompile VirtualBox and put back additional methods for locking - but I
was wondering don't you guys ever experience the same issues (however since
you simply blit the pixels to the display I guess not :D).


> Actually I wonder why this worked for your in VBox 4.3 because if the 4.3
> framebuffer implementation
> used the guest VRAM directly, then it was the same case as in 5.0.
>
In VBox 4.3 we performed the RGB to NV12 conversion inside the notify
update callback and we also locked an internal critical section which also
was locked if IFramebuffer::Lock was called - so during the time while our
frontend was reading the pixels noone else could access them. This was
safe, but slow as hell. I mean the responsiveness of the guest OS has
become much much much better now with the normalized fps encoding instead
of reacting to every update.


> Do you remember whether the 4.3 framebuffer implementation allocated the
> memory and did not use VRAM directly?
>
We always used VRAM. If the amount of memory wasn't so high we could use
our own pointer and copy, but in case of a full screen video or OpenGL
redirection where we won't be able to simply copy smaller regions this will
be a performance pitfall.

Best Regards,
Rudolfs Bundulis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20160519/d20dd897/attachment.html>