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