Here are my slides from the BGL presentation -- you can treat them as public, and treat the 1.0 requirements attached as public also. Thanks again for the opportunity -- seems like it was very useful to get the dialog going. Rob BGL Requirements Version 1.0 February 4, 1999 Motivation BGL ("Broadcast Graphics Language") is intended to be a conformant OpenGL subset/extension for broadcast-enabled receivers. Why BGL? A new generation of consumer-oriented, media computing devices is emerging, including digital set-top boxes, Internet devices, and various digital media appliances. These environments overlap with traditional personal computers, and share common characteristics of rapidly expanding graphics capabilities, high-bandwidth communication interfaces, and standardized content platform capabilities. A common high-performance media API would greatly facilitate the emergence of these new high-performance consumer media environments. OpenGL, the preeminent cross-platform performance graphics API of the computing industries, is the obvious candidate for fulfilling this need. This document describes the core requirements for specifying how BGL can provide a solution for this digital media environment. 1.0 Compositor In the digital media environment, continuous, complete re-synthesis of the display is the rule, rather than the exception. Continuous blending of full motion video, 3D graphics, animated 2D graphics and high-quality typography into a seamless presentation is required. This continuous compositing process is a good match for OpenGL's rendering model, and serves as a defining focus for BGL requirements. 1.1 Compositing of multiple Surfaces. The Compositor is expected to blend session contributions from a wide variety of possible media types and rendering interfaces. As described in the following section, Surfaces provide a mediating abstraction between a specific localized rendering methodology and the parent Compositor. Surfaces are expected to present their render-able data in a unified format, suitable for real-time composition. 1.2 Run-time performance profiling for scaleable content. In many applications, the Compositor will be required to completely regenerate the display within a fixed, full-motion frame rate, in order to maintain an acceptable quality of viewer/user experience. In the process of achieving this, it is expected that Compositor implementations will require mechanisms in BGL for governing scene-complexity/frame-rate tradeoffs. 1.3 Performance optimizations must not require content awareness. In the course of alpha-blending disparate, layered Surfaces, the Compositor may take advantage of various optimizations to sustain acceptable performance. This may involve hardware optimizations, such as the use of built-in overlay planes. This may also involve software optimizations, such as depth-complexity reduction and damage-repair propagation. However, content portability requires that these optimizations occur implicitly, as part of the implementation of the specific Compositor, rather than as specific content declarations. 2.0 Surfaces The alpha-blended, layered digital media environment of the Compositor updates the traditional role of the windowing system, allowing multiple media contexts to be rendered simultaneously on the same screen. For example, games, digital multimedia, and digital video effects extend beyond the windowing metaphor, with requirements of multimedia object rendering, multiple media surfaces, and synchronized rendering. The Surface is introduced as the context for addressing these requirements. 2.1 Support multiple rendering contexts. More than one thing at a time needs to happen on screen. These multiple contexts may come from different applications or content sessions that are mutually unaware of each other. 2.2 Support synchronized composition. The simultaneous rendering of multiple media types like 3D, video, and animation require management of the clock and resource prioritization in order to achieve consistent frame rates and deliver a satisfying viewer/user experience. 2.3 Support domain-specific rendering methodologies. It is expected that one or more Surface implementations will be defined for various Video, 2D, and 3D rendering contexts. While all Surfaces are required to deliver their contents in a unified format, suitable for efficient re-composition, each Surface may support its own rendering API, suitable for its own media-type-specific task. 2.4 Multiple Surface composition. To support meaningful compose-ability across various media types, each Surface is expected to be able to map and render any other Surface onto its own Surface. For example, a 3D Surface may employ another Video Surface or 2D Surface as a texture, to be mapped onto various 3D objects within its domain. Similarly, the rendered results of a 3D Surface or Video Surface may be mapped by the API of a 2D Surface, where they can be clipped by the anti-aliased curvature of a clip-path. 2.5 Surfaces as buffers. Surface rendering methods which are not prepared to deliver in real-time may use their Surface as a buffer, in order to support the continuous blending demands of the Compositor. 2.6 Extended surface abstractions. Surfaces are expected to present their render-able data in a unified format, suitable for real-time composition. Considerations for this unified format should not be limited to the familiar 2D array of color bit planes (color channels) and transparency blending (alpha channel). The surface interface should include a mechanism for recognizing additional channels as well-defined extensions to the compositional semantics of surfaces. For instance, there is particular interest in full-featured "deep" surfaces, including Z information per pixel (depth channels), and possibly additional masking information (stencil channel). 3.0 Build on existing 2D and video APIs 3.1 Enable transition from existing video, 2D, and vector/font rendering APIs. It will be necessary to interface BGL low-level primitives to existing video and 2D APIs, high-level widget libraries and GUI builders. A feature reference that provides an example of the kinds of requirements for vector graphics is SVG (Scalable Vector Graphics), currently under specification at the W3C (see http://www.w3.org/TR/WD-SVGReq ). 3.2 Support animated images. BGL must support animated images such as .GIF files, sprites, and shape-based coding algorithms. 4.0 Profiling/Adapting OpenGL’s 3D functionality OpenGL has a history of being perceived as "too big for the job". When high-performance 3D graphics began to emerge on personal computers in the mid-1990s, OpenGL was initially dismissed by many as too workstation-oriented for PC 3D games, 3D multimedia, and desktop visual computing. Time, however, has validated the OpenGL approach. Today, OpenGL is more widely used than ever, and is a key graphics API on most every major computing platform and OS. However, the emergence of each new media environment has necessitated an examination of OpenGL's focus and evolution. The consumer media computing domain raises issues of footprint constraints, diverse device types, and the continuing need for conformance. OpenGL is not unique in undergoing a subsetting and componentization scrutiny for the consumer media domain. See, for example, the W3C's evolution of HTML into a "suite of XML tag-sets" adaptable to a variety of devices beyond desktop computers at http://www.w3.org/MarkUp/Activity.html. Profiling/adapting requirements: 4.1 Operate in embedded contexts. Many consumer media devices have system services entirely in flash or embedded memory, with no significant persistent storage. Moreover, system services need to be instantly accessible when content becomes available from broadcast, DVD or other high-bandwidth streams. This requires determining, precisely, how OpenGL services will "fit" on these devices. 4.2 Operate in footprint-constrained contexts. Many consumer media devices have limited memory, although this is evolving quickly. This requires operating in resource-constrained environments and/or reporting of available system resources for content scalability. 4.3 Support range of rendering architectures. Both immediate mode and tile-based rendering architectures are used in consumer devices and need to be supported by BGL. 4.4 Enable high-performance, feature-rich media. It would be a mistake to view the consumer media domain as simply low-performance "little PCs". On the contrary, this environment has high performance demands, such as alpha-blending, game-level performance, tight synchronization, high image quality, resolution and scalability, digital video effects, and more. BGL must provide core high-performance graphics functionality to support these needs. 4.5 Conformant. Conformance requirements have been a central success element of the OpenGL proposition, and BGL must both continue and expand on this conformance contract. Factors that require strong conformance include the fact that consumer digital media devices are difficult or impossible to upgrade in the field and consistent graphics performance is necessary for content consistence across broad networks-----Original Message----- From: Jon Leech To: Rob Glidden Date: Tuesday, March 16, 1999 1:35 AM Subject: Re: bgl info for ARB >On Wed, Mar 10, 1999 at 10:56:51PM -0800, Rob Glidden wrote: >> Thurs, March 18 in the afternoon is great. >> >> Thanks for inviting me. > > Hi Rob, > > Here's the ARB meeting agenda. You're welcome to attend for as much >or as little of it as you like; let me know if the 1-2 PM slot for BGL >on Thursday needs to be adjusted. > > > Draft ARB Meeting Agenda - March 1999 > >Thursday, March 18 > >9-9:30 Conformance / SI / ICD Status (Dave Story, Steve Wright) > >9:30-10:30 Invariance and GL extensions (Kurt Akeley) > >10:30-12:00 Extensions (David Blythe + others) > >12-1 Lunch > >1-2 Broadcast GL (Rob Glidden) > >2-3 OPC (Dale Kirkland) > >3-4 IP (Chris Frazier) > >4-5 Conformance (or continue Extensions, if more time needed) > >Evening Dinner (details provided by 3Dfx during the day) > > >Friday, March 19 > >8:30-9 ARB Members Mtg. (if needed - may not be) > >9-11 Conformance (cont.) > >11-12 GLX Protocol / GLX Interoperability > >12-1 Lunch > >1-2 New OpenGL platforms / Mailing Lists > >2-4 Java Bindings / Magician Status Report > >4-5 Open > > >---- > Jon Leech > Silicon Graphics >