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].
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
