Re: QT/OpenGL (Re: was Potential O'Reilly Cocoa books (was Docs))
Re: QT/OpenGL (Re: was Potential O'Reilly Cocoa books (was Docs))
- Subject: Re: QT/OpenGL (Re: was Potential O'Reilly Cocoa books (was Docs))
- From: Chris Gehlker <email@hidden>
- Date: Sun, 26 Aug 2001 01:40:05 -0700
On 8/25/01 10:25 PM, "Brent Gulanowski" <email@hidden> wrote:
>
My feeling after looking into the OpenGL part of this is that these media
>
interfaces will always be a layer which operate procedurally, since the only
>
way they can offer performance is to be essentially one-way data pipes: you
>
provide a stream of data and they process it into images/sounds as quickly
>
and/or as smoothly/efficiently as possible. Messaging and 2-way
>
communication only slow down the media presentation. So I figure that you
>
can model your data any way you want, but for presentation, convert it to
>
the array or struct preferred by the API, fire off your pointer, and then go
>
back to managing the model. OpenGL seems to me like a monolithic object
>
which is best thought of as a bottomless well. You can only judge if it's
>
working right by actually seeing what's on screen. Heck, just dropping
>
OpenGL from fullscreen to windowed mode apparently kills performance, and is
>
a prime example of the one-way street of OpenGL dataflow.
I think you're right about OpenGL and MIDI but I'm changing my mind about QT
somewhat. The more I thought about it the more it seemed that QT can be
divided fairly cleanly into media editing functionality and media playback
functionality. The playback functionality is analogous to OpenGL but the
editing functionality could be embodied in a Framework.
I somehow doubt that Apple will do this but I would love to hear different.
Whether many would give up Windows portability and use such a framework is
an open question.
--
In the midst of great joy, do not promise anyone anything. In the midst of
great anger, do not answer anyone's letter. -Chinese proverb