Re: Cocoa friendly Quicktime APIs?
Re: Cocoa friendly Quicktime APIs?
- Subject: Re: Cocoa friendly Quicktime APIs?
- From: Dietmar Planitzer <email@hidden>
- Date: Sat, 8 Mar 2003 20:24:12 +0100
On Saturday, March 8, 2003, at 03:30 PM, publiclook wrote:
I think part of the reason some people might want a Cocoa API for
Quicktime is that the current Quicktime API has to be the ugliest most
over complex C API ever produced. Many people identify the Quicktime
API as Carbon because all of the interfaces to it require Carbon
opaque types like FSRef, OSType, Handle, Ptr, GWorldPtr,
PixMapHandle, FSSpec, GraphicsImportComponent,
GraphicsImporterComponentType, ComponentDescription,
ImageDescriptionPtr, Component, MatrixRecord, and OSErr.
Did anybody ever use NeXTtime ? Was is cleaner ?
I personally never used it, but I saw the header files and a little bit
of documentation.
Judging from the headers, NeXTTime was much, much cleaner organized. In
fact, I would say that design wise QT could take at least two dozened
chapters from the NT book. Sure, one important reason for NTs better
cleaness was that it simply didn't implement as much functionality as
QT, however, another one was that it strongly took advantage of
Foundation.
I.e. sample descriptions were simply represented as NSDictionaries. NT
just defined a bunch of key - value pairs - simple and easy. The big
advantage of this system compared to QTs various sample description
structures was that it provided one _single_ mechanism which was very
easy to extend. Compare this to QTs solution, where special API had to
be introduced just to deal with sample description extensions - one for
sounds plus another, redundent one for video.
Strings in NT were simply represented by NSStrings. Collections as
NSArrays (i.e. the alternate track list was a simple NSArray - in QT
its an obscure list). Atom containers as property lists (NSDictionary,
NSArray...). The API also used a lot the delegation and notification
concepts. I.e. NTClock, NTs basis class for all clocks, supported
delegates which got nice messages like -clockWillStart:,
-clockDidStart: or -clockDidChangeDirection. A similar interface
existed for slaving clocks together.
Further, as far as I can tell, NT was not hooked into an application's
event loop. Rather it ran as a server and took advantage of real-time
threads.
Anyway, integrating QT and Cocoa would be drastically simplified if QT
would finally fully embrace CoreFoundation and if some Cocoa classes
like NSImage would be slightly changed. Thus, sample descriptions
should be CFDictionaries; strings should be CFStrings rather than
Pascal strings. All file locations should be expressed as CFURLs. QT
should finally understand that the world does not revolve around QD,
especially not on MacOS X where I want to use Quartz and/or OpenGL and
never ever want to see a CGrafPtr.
The problem with NSImage is that it currently always creates an
NSCachedImageRep in order to draw into. This is problematic if you want
to hand the pixels of your offscreen graphics to QT because you need a
pointer to the pixel data which NSCachedImageRep won't give you. The
problem could be easily solved if I could tell NSImage to use an
NSBitmapImageRep as its internal cache rather than the standard
NSCachedImageRep.
Regards,
Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.