Hi,
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.
Thanks,
Vitali.
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.pelen...@oracle.com
<mailto:vitali.pelen...@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.
Thanks,
Vitali.
Rūdolfs Bundulis wrote:
Hi,
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@virtualbox.org <mailto:vbox-dev@virtualbox.org>
https://www.virtualbox.org/mailman/listinfo/vbox-dev
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
