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: Brent Gulanowski <email@hidden>
- Date: Sun, 26 Aug 2001 01:25:00 -0400
[Newbie]
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.
Unfortunately this works only for games and other media where the user is
primarily an observer operating a few limited controls. With a 3D modelling
app, say, you need to layer on a custom view that is sensitive to the user's
actual interactions with models, not just keyboard and mouse polling, so you
need to reassociate the 2D transform with the original 3D model: not easy to
do without repeating a lot of the work already done to get the 2D
rasterization made in the first place.
I'll be very happy if/when someone (might have to be me in a couple years)
writes a QD3D/Quesa-like library for Cocoa. But the 3D feedback will still
be stupid and one-way, I bet, because by the time the 3D models are
rasterized, the graphics card can't associate them with the mouse (or
whatever) any more. I'm wondering what the solution will be to this one-way
interactivity problem... I'll be even more happy when that comes around.
Seemingly hardware acceleration does not mix well with OOP. Aren't OpenGL,
Quicktime, MIDI etc just hardware abstractions?
For now, I'm guessing that the trick is to minimize the number of objects in
an app which are used to communicate with the media APIs -- perhaps even
using a single class with a uniqe instance for each media type:
MyOpenGLController, MyQuicktimeController, MyMIDIController (?), or
what-have-you, perhaps sharing a protocol to do whatever they would all have
to be able to do for each API, to let me query the presence/version and
installed capabilities of the pipeline before starting to feed it a steady
diet of un-encapsulated data.
Then again, I'm sure there are more gnarly issues from the viewpoint of the
experienced Cocoa developers.
BG
>
>
I'm afraid it's not going to change at all. QuickTime is, mostly, portable
>
to Windows and really old versions of MOS. It even builds in the old Mac
>
memory manager stuff on Windows. I can't really see Apple breaking the
>
portability so I think it will stay straight C.
>
>
Even for Cocoa programmers QT is just this thing sitting off by itself. It's
>
Pascal roots really show.
>
>
AFAIK, the situation with OpenGL is pretty much the same except it doesn't
>
address memory management and Apple doesn't control the API.