Inline movies in OmniWeb 2.0

William Shipley wjs
Wed Jun 14 21:39:06 PDT 1995


It would require NeXT to publish the specs on NEXTIME, something I suspect  
they won't do in the near future since I don't think NEXTIME has been the  
money-maker some had hoped.

Sadly, the real win in NEXTIME is being overlooked - its ability to provide  
an optimised, device-independent path to the framebuffer.  Interceptor is  
nice (and undocumented), but isn't device-independent.  (Eg, you get to  
write your drawing routines 7 times: 2 bit, 8 bit gray, 8 bit pseudo, 12  
bit, 15 bit, 24 bit low, and 24 bit high.)

My understanding of NEXTIME is that it allows you to give it a buffer and  
tell it what the format is, and it'll handle getting it to the screen  
quickly and dithered.  This would be an incredible boon to anyone doing  
interactive graphics applications under NEXTSTEP.  (If you doubt there are  
many of these, consider the Trilobyte and Id both develop on NEXTSTEP.)

We could do MPEG or MPEG2 ourselves, but our feeling is that since almost  
nobody has a fast enough network to view these real-time (as they are  
downloaded), it doesn't really matter if we do it inline or with another  
app.

Things like Gif and JPEG images, however, should be displayed incrementally  
inline because they don't have a minimum acceptable data rate.  (You can  
spend as much time as you want loading a GIF, you can't go below a certain  
transfer rate for MPEG and MPEG2.)

-Wil


More information about the OmniWeb-l mailing list