<br><div class="gmail_quote">On Fri, Apr 27, 2012 at 9:12 PM, Ivo Smits <span dir="ltr"><<a href="mailto:Ivo@ufo-net.nl" target="_blank">Ivo@ufo-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Op 27-4-2012 14:48, Klaus Espenlaub schreef:<br>
<div class="im">> On <a href="tel:27.04.2012%2008" value="+12704201208">27.04.2012 08</a>:56, Jaikumar G wrote:<br>
>> On Thu, Apr 26, 2012 at 10:48 PM, Klaus Espenlaub<br>
>> <<a href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a><mailto:<a href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a>>> wrote:<br>
>><br>
>> On <a href="tel:27.04.2012%2002" value="+12704201202">27.04.2012 02</a><tel:27.04.2012%2002>:43, Jaikumar G wrote:<br>
</div><div class="im">>> > Is my understanding of the API incorrect ? If I want to have the<br>
>> display<br>
>> > in another process - can I access the vram pointer directly -<br>
>> instead of<br>
>> > creating a shared buffer and passing it in the IFramebuffer<br>
>> implementation ?<br>
>><br>
>> This interface method isn't directly intended for using shared memory<br>
>> (but it might work if the VM frontend knows how to handle it), and it<br>
>> can only be used by the VM frontend itself, as pointers make no sense<br>
>> across processes.<br>
>><br>
>><br>
>> So whats the recommended way of sharing the display buffer if the<br>
>> frontend is running in another process ?<br>
> There is no recommended way so far - we didn't have the need for moving<br>
> the display buffer into another process, and others didn't need it<br>
> either. Heard of several people who rolled their own VM frontend (some<br>
> even in VisualBasic), keeping the display buffer local. It's the most<br>
> efficient solution, as it keeps the screen updates (which need a very<br>
> high bandwidth with a low latency to give a good interactive<br>
> performance) withing the process.<br>
><br>
> If you really want to go there you're the pioneer.<br>
</div>No, he's not. I have an IFramebuffer implementation that uses shared<br>
memory (a sufficiently large memory mapped file, on Windows) and passes<br>
this pointer to VirtualBox as the framebuffer address. The shared memory<br>
is then displayed/read in another process (update/resize events are<br>
passed using the standard input/output pipes). This works quite well. A<br>
funny side effect is that you can actually read the file as a (raw<br>
bitmap) image file.<br>
<br>
One important thing: memory pointers are in the context of the process.<br>
If you want to share memory between processes, you will somehow have to<br>
obtain a pointer to the actual region in memory, in both processes. A<br>
common and convenient way to do so is by mapping a file into memory, in<br>
both processes.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ivo<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
vbox-dev mailing list<br>
<a href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a><br>
<a href="https://www.virtualbox.org/mailman/listinfo/vbox-dev" target="_blank">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a><br>
</div></div></blockquote></div><br>I experienced cross-process sharing a framebuffer. I used a Linux(Unix) SHM to share the memory. as far as you handle the update carefully, like using a semaphore to sync between processes, it works well.<div>
<br></div><div>Have to mention, my experiment is using VRDP interface instead of IFramebuffer. But i believe it should be same, since VRDP expose framebuffer's pointer anyhow.<br clear="all"><div><br></div>-- <br>-Howard<br>
</div>