Re: [Opensg-users] FBO Window

[Michael R. <mic...@gm...>]

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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>