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 <[email protected]>: > 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 >> [email protected] >> https://www.virtualbox.org/mailman/listinfo/vbox-dev >> > >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
