theatertrio.blogg.se - Request throttled new world

Request throttled new world driver#
Request throttled new world full#
Request throttled new world windows#

needs to be defined, can fail if driver can't handle requested number of buffers TBD_swap_control - allow selection triple/N bufferingġ.SGIX_swap_barrier - controls swap group behavior.for redirected windows, swap groups could depend on compositor copies (see SBC count above) SGIX_swap_group/ NV_swap_group - allow clients to swap in a synchronized mannerġ.

Request throttled new world windows#

the way X and compositors work now make it hard to report anything other than 'unknown' as the swap method page flipping is opportunistic, and exchange is difficult for windows (redirected or not) due to reparenting by window managers

OML_swap_method - exposes swap method (whether copy, exchange or undefined) to the FBconfigġ.

for redirected windows, SBC could be incremented when the compositor copies a buffer rather than when the buffer is copied from back to front for redirected windows, MSC represents the compositor frame count likewise UST indicates the time when the compositor last generated a frameġ.

OML_sync_control - combines the above and adds the notion of a "swap count" and frame timestamp, allowing applications to closely monitor their performance and swap frequencyġ.

for redirected windows, glXWaitVideoSyncSGI will block until the compositor frame count satisfies the specified conditions for redirected windows, glXGetVideoSyncSGI returns the compositor frame count rather than the monitor frame countġ.

SGI_video_sync - allows clients to query frame counts and wait on specific counts or divisor/remainders thereofġ.

for redirected windows, interval is in compositor frames rather than monitor video frames

SGI_swap_control - controls how frequently glXSwapBuffers swaps occur (in frames)ġ.

the compositor may report 60fps to applications even though it only updates the screen when recompositing is needed): Changes noted below, though in general "video frame" should be thought of as a virtualized compositor frame rate rather than a monitor refresh (e.g. Under a compositor, the behavior of these routines could change, or additional compositorclient protocol added to support similar behavior. OpenGL and GLX swap and throttling related extensions queue if the buffers are rendered faster than can be displayed

triple buffering should be available to applications that need it, with configurable behavior for discard vs.

to preserve back buffer contents after a swap)

some applications want to control how buffer swaps occur (e.g.

Request throttled new world full#

page flipping for full screen swaps is also a significant win on bandwidth limited platforms.exchange is only possible if front & back window pixmaps are the same size) * requires window managers to draw decorations independent of application window (i.e. performance could be significantly improved on low bandwidth platform if buffer swaps could be simple pointer exchanges when windowed (similar to the way page flips work for full screen applications).* This can happen automatically with some additions to the DRI2 protocol and client/server behavior. it could also be reduced by throwing away the private back buffer in between frame rendering.* This can be implemented purely client side through the addition of compositorclient protocols. memory consumption could be reduced if the private back/front pair was reduced to just a private back with the compositor copy acting as front (though there are issues with front buffer rendering in this case).There are also issues related to memory consumption, swap behavior, and performance that can be addressed: Memory savings Plain X doesn't have many ways of doing the above (it mostly assumes immediate mode drawing to the visible frame buffer), but GLX provides many extensions related to handling the actual display of buffers on the user visible screen, these extensions need to be supported in DRI2 for the Linux graphics stack to really shine. performance - apps need to know how well they're keeping up with their desired frame rate so they can throttle back or simplify drawing as needed.smoothness - constant, predictable frame rates are a requirement for animation, video and high end simulation programs.preventing distracting artifacts - ugly "tearing" or partial drawing for example.X and GL applications need to control how their data is displayed for several reasons: