Hi Vitali, thanks for clearing all of this out - this should be sufficient to make the transition.
2016-01-05 11:22 GMT+02:00 Vitali Pelenjow <vitali.pelen...@oracle.com>: > Hi Rudolfs, > > if you are launching the machine inside you own process, then use > notifyUpdate. You are right that in this case you get the pointer to the > framebuffer bitmap using the IDisplaySourceBitmap interface. > > You should call IDisplaySourceBitmap::queryBitmapInfo from notifyChange > handler (see implementations in src\VBox\Frontends). The returned bitmap > info is valid until the next notifyChange call. > > notifyUpdateImage is used to get bitmap updates in a different process. > > Thanks, > Vitali > > Rūdolfs Bundulis wrote: > >> Hi, >> >> I am porting my custom frontend to VirtualBox 5.0 and had a couple of >> questions about how IFramebuffer works now. I see that all the stuff >> regarding VRAM and implementing it inside the framebuffer is gone, which I >> was told would happen. What confuses me is usage of notifyUpdate vs >> notifyUpdateImage. I am launching the machine inside my own process - so >> then which is the most efficient way to receive notifications about >> updates? Which one is more efficient? As I understand if I use notifyUpdate >> (and do not retur the UpdateImage capability) I must get the pointer to the >> bitmap and all the data from the IDisplaySourceBitmap interface? Is that >> thread safe? Can I read the pixels without any explicit locking? And what >> about changes to the pixel format - they are no longer part of the >> notifications. Does that mean I need to call >> IDisplaySourceBitmap::queryBitmapInfo() each time i receive a notifyUpdate >> call? >> >> Best Regards, >> Rudolfs Bundulis >> >> >> _______________________________________________ >> 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