Am 28.11.2011 17:38, schrieb Carsten Neumann: > Hello Michael, > > On 11/28/2011 09:52 AM, Michael Raab wrote: >>> I think from a practical standpoint this can work. The only issue I see >>> is that a Window in OpenSG is representing an OpenGL context, so in that >>> sense a FBOWindow does not fit well into the picture. The FBOWindow >>> would probably need to contain a pointer to the "real" Window and >>> forward certain calls to it to make it work in places where OpenSG >>> accepts windows. >>> An alternative could be to separate the FBO and the FBOViewport by >>> creating a FrameBufferObject class that represents the FBO and can be >>> shared by multiple FBOViewports. >> Hmm, ok. What I'm searching for is a solution that would both fit for me but >> as well for the OpenSG community in general. > thanks, it's appreciated! > >> For me both solutions would be ok, but in my opinion creating a 'FBOWindow' >> class may require less programming work as the current FBOViewport >> implementation (which is huge) can be left untouched. > you are probably right, although a large portion of code in FBOViewport > is dealing with emulating FBO functionality if it is not supported by > the hardware, the hardware accelerated code path is actually not that > much code. Splitting some of that functionality into more helper > functions instead of ~1k line monsters would be a great cleanup :) > >> Regarding cleanness of the approach I would rely on your knowledge of the >> overall OpenSG approach. >> So what do think about the direction to go? > Well, we are talking about 1.x here, and this is a part that has changed > significantly in 2.0 to address the shortcomings you are running into. > To me backporting all that to 1.x does not seem like the best use of > time here and is quite a bit of work. So, if you like to do something > that improves the situation for 1.x users, splitting out the FBO from > the FBOViewport seems like a reasonable compromise to me [1]. > If that exceeds the amount of time you can commit to, I'd say pick > whatever solves your immediate needs, which may well be the FBOWindow > solution, although IMHO it does not fit well into the overall system [2]. Hmm, time is short and the fact that don't know much about the details of the current FBOViewport is not a good precondition ;-) So I'll try and give my best to create the 'FBOWindow' solution.
Thanks, Michael > Cheers, > Carsten > > [1] Keeping existing code from breaking may make this more tricky > unfortunately :-/ > > [2] We can still add it to the repository, although I'd probably put a > big warning sticker on it ;) > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
