On Tue, Sep 17, 2002 at 09:57:35AM -0700, Keith Packard wrote: | | The alpha incompatibility leads from the separation of alpha values from | the core X pixel values in OpenGL; OpenGL uses separate visuals which mark | support for per-pixel data which is invisible through the X protocol. ...
>From the beginning OpenGL needed to support deep integer (and now floating-point) color channels as well as alpha and other data, so there wasn't much choice but to provide an upwardly-compatible extension to the Visual services offered by the core X11 protocol. Render needs some of those features today, and probably will want more of them in the future. The questions several of us are politely dancing around are "Since there's already such a mechanism, why doesn't Render use it? If the existing mechanism isn't quite right, why not extend it rather than creating a new one which is incompatible?" The same questions arise in plenty of other contexts. For example, Render implementations might want to treat images as textures so that the hardware can accelerate projective transformations of those images. It would be nice if Render piggybacked on the OpenGL "pbuffer" or texture storage mechanisms, rather than creating a new one which introduces contention both for a physical resource and for the scarce engineer-hours needed to build and maintain drivers. I'm not saying all this would be easy, or that OpenGL already provides everything that Render might need. But integrating 2D, 3D, and imaging via the 3D API is the way Microsoft is going and Apple has already gone, and was one of the design goals for OpenGL. Consumer-class hardware already provides most of the functionality and performance needed for this in the PC space, and is getting cheaper and more capable very quickly. Moving down-market into small and embedded systems is one of the high priorities for OpenGL 1.X and 2.0 subsets, as cost- and power-reduction efforts make accelerator hardware feasible there. Sorry for the rant; I guess I feel it necessary to repeat it occasionally in hopes that we can keep our efforts from drifting too far apart. Allen _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
