| Name |
| |
| SGIS_blended_overlay |
| |
| Name Strings |
| |
| GLX_SGIS_blended_overlay |
| |
| Version |
| |
| $Date: 1997/10/29 20:56:43 $ $Revision: 1.5 $ |
| |
| Number |
| |
| 142 |
| |
| Dependencies |
| |
| EXT_visual_info is required |
| GLX_SGI_color_range affects the definition of this extension |
| |
| Overview |
| |
| This extension augments the set of transparency types for GLX |
| visuals (defined by the EXT_visual_info GLX extension). A new |
| transparency type designated BLENDED_RGBA_SGIS is defined for |
| overlay windows supporting an alpha color component. Instead of |
| using a particular transparent pixel or color value to indicate |
| transparency, a window created with a BLENDED_RGBA_SGIS |
| transparency type visual blends with the lower frame buffer layers |
| based on the overlay window's per-pixel alpha component. |
| |
| The overlay blend function is: |
| |
| if ( Cu is color index pixel type ) then |
| |
| if ( Ao > 0.0 ) then |
| Cd = Co /* Non-zero overlay alpha simply uses overlay color */ |
| else |
| Cd = Cu /* Note: later CI cmap turns Cd index into true color */ |
| endif |
| |
| else /* Cu is an RGBA, RGB, L, or LA pixel type */ |
| |
| /* blend overlay color with normal color based on overlay alpha */ |
| Cd = Co * (Ao,Ao,Ao,Ao) + Cu * ( (1,1,1,1) - (Ao,Ao,Ao,Ao) ) |
| |
| endif |
| |
| where Cd is the resulting displayed color. Co is the RGBA |
| quadruplet for the overlay RGBA components of the overlay window |
| pixel. Ao is the alpha component for the overlay alpha component |
| of the overlay window pixel. Cu is the RGBA quadruplet for the |
| RGBA components of the displayed pixel if no overlay where present |
| in the overlay window's layer (or any higher level). Think of Cu |
| as the displayable color "under" the BLENDED_RGBA_SGIS overlay |
| pixel. |
| |
| In the case of extended range frame buffer formats, the overlay |
| blend function is applied post-clamping to the [0,1] range. |
| |
| Here are some of the uses for blended RGBA overlays: |
| |
| Render antialiased lines, points, and polygons in the overlays |
| with GL_LINE_SMOOTH, GL_POINT_SMOOTH, and GL_POLYGON_SMOOTH. |
| |
| Alpha blended antiliasing could be used on the overlay boundaries |
| of overlay control panels and boat hulls. |
| |
| Clean blending of overlaid mattes for live video. Live video |
| stream could be overlaid by computer generated overlaid |
| graphics. |
| |
| Swank user interface support for sweeping out irregular screen |
| regions by painiting the region in the overlay with a fractional |
| alpha to blend the sweeped region with some constant color in the |
| overlay. |
| |
| Swank brush shapes for 3D painting that let you see the blended |
| pixels underneather the overlay brush shape. |
| |
| Really smooth (ie, subpixel positioned), full-color, antialiased |
| cursors (application drawn into a blended RGBA overlay). |
| |
| IP Status |
| |
| Silicon Graphics has filed for patent protection for some of the |
| techniques described in this extension document. |
| |
| Issues |
| |
| * Are any other blending functions interesting? NO. |
| |
| * Rather unlikely but you could have multiple layers of blended |
| overlays and/or normal overlays. If two layers of blended overlays |
| were present, the upper layer should be blended with the resulting |
| blend of the lower overlay with the normal plane. YES. |
| |
| (Warning, be careful about multiple blending using |
| non-premultiplied alpha. See Porter & Duff SIGGRAPH paper.) |
| |
| * X does not all rendering in the alpha bitplanes. X rendering |
| should be assumed to always draw an alpha of 1.0. This means that |
| a BLENDED_RGBA_SGIS overlay will act as an overlay with no |
| transparent pixel when it comes to X rendering. Blended overlays |
| overlays will only be usable for transparency via OpenGL |
| rendering. The SEVER_OVERLAY_VISUALS (SOV) X convention will |
| therefore advertise the visual as having transparency type None (no |
| new transparency type will be added to SOV). YES. |
| |
| * If the alpha component of the frame buffer is displayable (ie, sent |
| out with the video signal), what alpha value should be generated |
| when blended overlays are present? Is the resulting blended alpha |
| what you would want? Perhaps merely sending the normal plane alpha |
| is better. Unresolved. |
| |
| * Should frame buffer layers that supporte extended precision (via |
| the GLX_SGI_color_range extension) be blended before clamping |
| the color components to [0,1]? NO. |
| |
| Both the overlay and normal layer must both be clamped to [0,1] |
| before the overlay blend function is performed. |
| |
| * Does the overlay's full alpha component precision need to be |
| used for the overlay blend function? NO. |
| |
| For example, if the overlay had 8 bits of alpha, the overlay |
| blend function might "get away with" only blending with the 4 |
| most significant bits of the alpha component. This might allow |
| cheaper multipliers for the bandwidth-intensive overlay blend |
| function. There is no direct way to query what alpha precision |
| the overlay blend uses. Obviously, implementations are |
| encouraged to use as much overlay precision as is available. |
| |
| * How does a blended overlay interact when it covers a color index |
| window? If the overlay alpha is zero, use the color index |
| pixel. A non-zero alpha simply uses the overlay color as is. |
| |
| * How does a blended overlay interact when it covers an X |
| DirectColor visual? DirectColor has RGB components that are |
| then passed through (generally as part of video scan-out) a |
| per-component colormap (ie, look-up tables). (The DirectColor |
| colormap is often implemented by overloading the gamma tables). |
| |
| Arguably, the blending should use the post-DirectColor colormap |
| color values (same for color index, PseudoColor, etc), but in |
| practice, this is a colormap lookup that typically happens |
| within the video display subsystem so it is not reasonable to |
| expect the overlay blending be put off so long. |
| |
| RESOLUTION: DirectColor visual color components should overlay |
| blended pre-DirectColor colormap conversion. In practice, this |
| means that DirectColor will be treated no differently from |
| TrueColor visuals. |
| |
| * What is the relationship between blended overlays and channel |
| compositing? None, they are independent and orthogonal |
| features. Channel compositing happens well after blended |
| overlays. |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| Returned by glXGetConfig, and accepted by the <attrib_list> |
| parameter of glXChooseVisual (following the GLX_TRANSPARENT_TYPE_EXT |
| token): |
| |
| GLX_BLENDED_RGBA_SGIS 0x8025 |
| |
| (EXT_visual_info previously defined GLX_NONE_EXT, |
| GLX_TRANSPARENT_RGB_EXT, and GLX_TRANSPARENT_INDEX_EXT.) |
| |
| Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation) |
| |
| None |
| |
| Additions to Chapter 3 of the 1.0 Specification (Rasterization) |
| |
| None |
| |
| Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations and |
| the Framebuffer) |
| |
| |
| Additions to Chapter 5 of the 1.0 Specification (Special Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the 1.0 Specification (State and State Requests) |
| |
| None |
| |
| Additions to the GLX Specification |
| |
| Changed beginning of the paragraph from the EXT_visual_info |
| specification: |
| |
| The visual attribute GLX_TRANSPARENT_TYPE_EXT indicates whether |
| or not the visual supports transparency, and if it does support |
| transparency, what type of transparency is available. If the |
| attribute is set to GLX_NONE_EXT then windows created with the |
| visual will not have any transparent pixels. If the attribute is |
| GLX_TRANSPARENT_RGB_EXT, GLX_TRANSPARENT_INDEX_EXT, or |
| GLX_BLENDED_RGBA_SGIS then the visual supports transparency. ... |
| |
| Add the following paragraph after the discussion of paragraph from |
| the EXT_visual_info specification addition beginning "The visual |
| attribute GLX_TRANSPARENT_TYPE_EXT indicates..." |
| |
| GLX_BLENDED_RGBA_SGIS is applicable to TrueColor and DirectColor |
| visuals. There is no particular transparent pixel value for this |
| visual. Instead, the alpha component of pixels belonging to the |
| overlay window are used to blend the overlay color with the |
| displayable color of the frame buffer layers below the |
| GLX_BLENDED_RGBA_SGIS overlay pixels. |
| |
| The GLX_BLENDED_RGBA_SGIS overlay blend function is: |
| |
| if ( Cu is color index pixel type ) then |
| |
| if ( Ao > 0.0 ) then |
| Cd = Co /* Non-zero overlay alpha simply uses overlay color */ |
| else |
| Cd = Cu /* Note: later CI colormap turns Cd index into true color */ |
| endif |
| |
| else /* Cu is an RGBA, RGB, L, or LA pixel type */ |
| |
| /* blend overlay color with normal color based on overlay alpha */ |
| Cd = Co * (Ao,Ao,Ao,Ao) + Cu * ( (1,1,1,1) - (Ao,Ao,Ao,Ao) ) |
| |
| endif |
| |
| where Cd is the resulting displayed color. Co is the RGBA |
| quadruplet for the overlay RGBA components of the overlay window |
| pixel. Ao is the alpha component for the overlay alpha component |
| of the overlay window pixel. Cu is the RGBA quadruplet for the |
| RGBA components of the displayed pixel if no overlay where present |
| in the overlay window's layer (or any higher level). Think of Cu |
| as the displayable color "under" the BLENDED_RGBA_SGIS overlay |
| pixel. |
| |
| In the case of extended range frame buffer formats (from the |
| GLX_SGI_color_range spec), the overlay blend function is applied |
| post-clamping to the [0,1] range during display scan out. |
| |
| Changed paragraph from the EXT_visual_info specification: |
| |
| If GLX_TRANSPARENT_TYPE_EXT is GLX_NONE_EXT, |
| GLX_TRANSPARENT_RGB_EXT, or GLX_BLENDED_RGBA_SGIS, then the value |
| returned for GLX_TRANSPARENT_INDEX_VALUE_EXT is undefined. If |
| GLX_TRANSPARENT_TYPE_EXT is GLX_NONE_EXT, |
| GLX_TRANSPARENT_INDEX_EXT, or GLX_BLENDED_RGBA_SGIS, then the |
| values returned for GLX_TRANSPARENT_RED_VALUE_EXT, |
| GLX_TRANSPARENT_GREEN_VALUE_EXT, and |
| GLX_TRANSPARENT_BLUE_VALUE_EXT are undefined. |
| |
| Change line in Table 1 to the following: |
| |
| Attribute Type Notes |
| --------- ---- ----- |
| GLX_TRANSPARENT_TYPE_EXT enum None, TRANSPARENT_RGB_EXT, TRANSPARENT_INDEX_EXT, |
| or BLENDED_RGBA_SGIS |
| |
| Table 1: Configuration attributes |
| |
| GLX Protocol |
| |
| One property type/property value pair is augmented with a new |
| proprty value. The augmented property type/property value pair is |
| now encoded as |
| |
| 4 ENUM property type |
| 0x23 GLX_TRANSPARENT_TYPE_EXT |
| 4 ENUM property value |
| 0x8000 GLX_NONE_EXT |
| 0x8008 GLX_TRANSPARENT_RGB_EXT |
| 0x8009 GLX_TRANSPARENT_INDEX_EXT |
| 0x8025 GLX_BLENDED_RGBA_SGIS |
| |
| Errors |
| |
| None |
| |
| New State |
| |
| None |
| |
| New Implementation Dependent State |
| |
| None. |
| |