If you have any further questions of this nature, please send them to VirtualGL-Devel, not to this list.
On 6/15/15 3:07 PM, Marco Marino wrote: > Hi Nathan, thank you for your answer. > I read the code of the plugin (a good way to fun in the sunday....).... > some consideration and few questions here: > > - in server/testplugin.cpp there are 2 functions, RRTransSendFrame and > RRTransGetFrame. These 2 functions should be the important part of the > transport plugin because they are called respectively from the server > and the client, right? No, they are both called from the server. VirtualGL calls RRTransGetFrame() in order to get a new frame from the plugin, and it calls RRTransSendFrame() to send it. > - In RRTransSendFrame i have "vglconn->sendFrame". But vglconn is the > "handle" and hence is the VGLTrans() (in the case of testplugin.cpp, so > i think the important part of the sendFrame resides in the VGLTrans > class. But the VGLTrans class calls _VGLTrans_spoilfct method and it > seems that lock and the unlock the thread using the method > signalComplete. What happens here? I don't understand the signalComplete > method. Can you help me please? The test plugins use the existing transport classes (VGLTrans for the VGL Transport, or X11Trans for the X11 Transport.) Your plugin will be providing its own transport, so you should not use those existing transport classes, although you might want to base your own transport class on one of them. Please do not expect this to be a quick project. You're going to have to spend many hours digging into how this stuff works before you can successfully write your own transport. > Thanks, > MM > > > > 2015-06-15 21:40 GMT+02:00 Nathan Kidd <nathan...@spicycrypto.ca > <mailto:nathan...@spicycrypto.ca>>: > > On 13/06/15 09:56 AM, Marco Marino wrote: > > I understand your point of view, but without any documentation (and a > > bit of help) is impossible for me develop such transport plugin. > > Hi Marco, > > Having used the plugin API and put my own transport layer in VGL > directly in the past, my free and unsolicited advice is: > > 1) using the API is simple, just copy the existing examples > > 2) if you're up for making H.264 work then the work to grok the plugin > system is a minor blip in the workload. Don't let lack of documentation > stop you; you don't really need it. > > Cheers, > > -Nathan > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
