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