[vbox-dev] D3D support in custom frontend

Rūdolfs Bundulis rudolfs.bundulis at gmail.com
Mon Feb 16 10:16:58 GMT 2015


I wanted to possibly get some clarification if a delay in the
IFramebuffer::notifyUpdate can cause issues?

I'm still trying to deal with the longjmp crash, I tried to examine the
code of the frontends and see if I'm doing anything wrong (initially I
thought that maybe using MTA instead of STA could break something, since
all the frontends with GUI use STA, but then I came to the conclusion that
VBoxHeadless also uses MTA, and switching my code to STA didn't improve
anything). So I basically wrote another small application that would just
BitBlt the vram contents on a window DC and that seemed to work fine even
with multiple CPUs. Then I thought that maybe when using MTA I need to make
an additional lock (the frontends basically just lock thesmelves when the
Lock(), Unlock() methods are called, but there is no additional lock for
all the internal variables like height, widht, etc., and there is a comment
that it should be fine since the requestResize/lock/unlock/notifyUpdate
flow remove the need for a lock for these variables). After introducing
another lock I was actually able to start my code with multiple CPUs at low
resolutions just fine, although on extreme resolutions the crash appeared
again, so I started leaning towards having a race condition somewhere. The
only explicit difference I see betweeen my application and the window DC
test and the original VirtualBox frontends is that notifyUpdate actually do
very little work - my application also does not perform anything excessive
there but still I do the RGB->YUV conversion that for large resolutions
still takes up some time. The reason why it's delaying is that I wanted to
make sure the buffer is not accessed by VirtualBox so I'm doing the color
conversion in notifyUpdate under the same lock that is used in
lock()/unlock(). If that is not feasible and the function should return
fast I can just lock the buffer and return and do the processing on another
thread, all I wanted to ask is just if there are any known issues with such

Best Regards,
Rudolfs Bundulis

2015-02-11 19:38 GMT+02:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com>:

> Hi Klaus,
> thanks for the pointers on VRDE, I looked at the sources and saw that the
> ConsoleVRDPServer.cpp actually does tell the service to perform a redirect
> by sending SHCRGL_HOST_FN_SET_OUTPUT_REDIRECT, so I guess to avoid having
> the windows I need to do the same and implement the callbacks, thanks for
> the tip.
> Best Regards,
> Rudolfs Bundulis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20150216/88e00a51/attachment.html>

More information about the vbox-dev mailing list