<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Vitali,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the guest may access the guest VRAM between NotifyUpdate calls.<br>
Which means that in principle the guest can change the content while the frontend thread is reading pixels.</blockquote><div>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<br></div><div>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).</div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Actually I wonder why this worked for your in VBox 4.3 because if the 4.3 framebuffer implementation<br>
used the guest VRAM directly, then it was the same case as in 5.0.<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you remember whether the 4.3 framebuffer implementation allocated the memory and did not use VRAM directly?<br></blockquote><div>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.</div><div><br></div><div>Best Regards,</div><div>Rudolfs Bundulis </div></div></div></div>