[vbox-dev] Synchronizing access to the framebuffer in VirtualBox 5
Vitali.Pelenjow at oracle.com
Thu May 19 19:21:14 UTC 2016
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.
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.
Do you remember whether the 4.3 framebuffer implementation allocated the
memory and did not use VRAM directly?
In this case you simply had the additional buffer, VRAM content was
copied to it.
The same can be implemented by the frontend in 5.0. I.e. NotifyUpdate
copies data to an intermediate buffer, which is encoded.
Rūdolfs Bundulis wrote:
> Hi Vitali,
> thank you for replying to this since this issue really does bother me.
> We are processing them in a different thread - we used to do that
> directly in the callback, but if the updates are frequent we cannot
> achieve a normalized frame rate for the encoded video stream of the
> desktop (and also we start to slow down the machine - running RGB to
> NV12 conversions for a 9600x5400 screen take some time, and if more
> than a single update occurs between two frames with a given rate there
> is not much sense running the conversion twice). Now we simply push
> the corrdinates from NotifyUpdate in a list, which is processed from
> another thread based on a timer which gives us normalized encoding times.
> So with such a scenario in mind - any ideas? :)
> 2016-05-19 21:56 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com
> <mailto:Vitali.Pelenjow at oracle.com>>:
> Hi Rudolfs,
> how the custom frontend reads pixels: directly in
> IFramebuffer::NotifyUpdate or from a different thread?
> If pixels are read in IFramebuffer::NotifyUpdate, then technically
> it should be ok, i.e. AFAIK the framebuffer
> it not changed at the time.
> Rūdolfs Bundulis wrote:
> after transferring my custom frontend code to VirtualBox 5 I
> started to notice small artifacts in the video stream - I
> assume since there are no more Lock() and Unlock() methods I
> may be reading the pixels while another update is actually in
> progress. Is there any mechanism to implement a syncrhonized
> access to the framebuffer (using something internal from vbox
> dlls is fine for me, I am already dynamically loading them to
> enable OpenGL redirection).
> Best Regards,
> Rudolfs Bundulis
> vbox-dev mailing list
> vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> vbox-dev mailing list
> vbox-dev at virtualbox.org
More information about the vbox-dev