mirror of
https://gitlab.freedesktop.org/xorg/proto/xorgproto.git
synced 2026-05-05 00:38:11 +02:00
Spelling and grammar fixes
Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
This commit is contained in:
parent
cd7b5a4bee
commit
29c53a28fa
6 changed files with 15 additions and 15 deletions
|
|
@ -35,7 +35,7 @@ both early prototypes and the final design include:
|
|||
a prototype of the coordinate transformation mechanism.
|
||||
|
||||
+ Ryan Lortie for helping figure out reasonable parent clipping
|
||||
semantics in the presense of manual redirected children.
|
||||
semantics in the presence of manual redirected children.
|
||||
|
||||
3. Architecture
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ the contents and to create a new name for the newly allocated pixmap.
|
|||
In automatic update mode, the X server is itself responsible for presenting
|
||||
the child window contents within the parent. It seems reasonable, then, for
|
||||
rendering to the parent window to be clipped so as not to interfere with any
|
||||
child window content. In an environment with a mixure of manual and
|
||||
child window content. In an environment with a mixture of manual and
|
||||
automatic updating windows, rendering to the parent in the area nominally
|
||||
occupied by a manual update window should be able to affect parent pixel
|
||||
values in those areas, but such rendering should be clipped to automatic
|
||||
|
|
@ -135,7 +135,7 @@ should be defined by the clients themselves.
|
|||
3.3 Clipping semantics redefined
|
||||
|
||||
Version 0.4 of the protocol changes the semantics of clipping in the
|
||||
presense of manual redirect children. In version 0.3, a parent was always
|
||||
presence of manual redirect children. In version 0.3, a parent was always
|
||||
clipped to child windows, independent of the kind of redirection going on.
|
||||
With version 0.4, the parent is no longer clipped to child windows which are
|
||||
manually redirected. This means the parent can draw in the child region without using
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
1. Introduction
|
||||
|
||||
The DRI2 extension is designed to associate and access auxillary
|
||||
The DRI2 extension is designed to associate and access auxiliary
|
||||
rendering buffers with an X drawable.
|
||||
|
||||
DRI2 is a essentially a helper extension to support implementation of
|
||||
|
|
@ -49,7 +49,7 @@ Stolen from OpenGL FBOs, I guess.
|
|||
|
||||
2.2. Kernel rendering manager
|
||||
|
||||
This specification assumes a rendering architechture, where an
|
||||
This specification assumes a rendering architecture, where an
|
||||
underlying kernel rendering manager that can provide 32 bit integer
|
||||
handles to video memory buffers. These handles can be passed between
|
||||
processes, which, through a direct rendering driver, submit rendering
|
||||
|
|
@ -57,7 +57,7 @@ to the kernel rendering manager, targeting and/or sourcing from these
|
|||
buffers. This extension provides a means to communicate about such
|
||||
buffers as associated with an X drawable.
|
||||
|
||||
The details of how the a direct rendering driver use the buffer names
|
||||
The details of how the direct rendering driver use the buffer names
|
||||
and submit the rendering requests is outside the scope of this
|
||||
specification. However, Appendix B does discuss implementation of
|
||||
this specification on the Graphics Execution Manager (GEM).
|
||||
|
|
@ -102,7 +102,7 @@ use DRI2CopyRegion to copy contents back and forth between the fake
|
|||
front buffer and the real front buffer. When X and direct rendering
|
||||
to a front buffer is interleaved, it is the responsibility of the
|
||||
application to synchronize access using glXWaitGL and glXWaitX. A
|
||||
DRI2 implementation of direct rendering GLX, should use these enty
|
||||
DRI2 implementation of direct rendering GLX, should use these entry
|
||||
points to copy contents back and forth to as necessary to ensure
|
||||
consistent rendering.
|
||||
|
||||
|
|
@ -419,7 +419,7 @@ The name of this extension is "DRI2".
|
|||
|
||||
Blocks the client until the swap buffer count reaches target_sbc. If
|
||||
the swap buffer count is already greater than or equal to target_sbc
|
||||
when the request is recieved, this request will return immediately.
|
||||
when the request is received, this request will return immediately.
|
||||
|
||||
If target_sbc is 0, this request will block the client until all
|
||||
previous DRI2SwapBuffers requests have completed.
|
||||
|
|
|
|||
|
|
@ -318,7 +318,7 @@ The name of this extension is "Present"
|
|||
PresentCapabilityFence means that the target device can take
|
||||
advantage of SyncFences in the Present operations to improve
|
||||
GPU throughput. The driver must operate correctly in the
|
||||
absense of fences, but may have reduced performance. Using
|
||||
absence of fences, but may have reduced performance. Using
|
||||
fences for drivers not advertising this capability should have
|
||||
no performance impact.
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ Version 1.5 adds monitors
|
|||
• A 'Monitor' is a rectangular subset of the screen which represents
|
||||
a coherent collection of pixels presented to the user.
|
||||
|
||||
• Each Monitor is be associated with a list of outputs (which may be
|
||||
• Each Monitor is associated with a list of outputs (which may be
|
||||
empty).
|
||||
|
||||
• When clients define monitors, the associated outputs are removed from
|
||||
|
|
@ -176,7 +176,7 @@ Version 1.5 adds monitors
|
|||
active outputs associated with them
|
||||
|
||||
This new object separates the physical configuration of the hardware
|
||||
from the logical subsets the screen that applications should
|
||||
from the logical subsets of the screen that applications should
|
||||
consider as single viewable areas.
|
||||
|
||||
1.5.1. Relationship between Monitors and Xinerama
|
||||
|
|
@ -235,7 +235,7 @@ implications of MST monitors and encouraging the introduction of the
|
|||
Screens may change dynamically, either under control of this extension, or
|
||||
due to external events. Examples include: monitors being swapped, pressing a
|
||||
button to switch from internal display to an external monitor on a laptop,
|
||||
or, eventually, the hotplug of a display card entirely on busses such as
|
||||
or, eventually, the hotplug of a display card entirely on buses such as
|
||||
Cardbus or Express Card which permit hot-swap (which will require other work
|
||||
in addition to this extension).
|
||||
|
||||
|
|
@ -621,7 +621,7 @@ The name of this extension is "RANDR".
|
|||
rate is unknown or on devices for which refresh is not relevant.
|
||||
|
||||
'sizes' is the list of possible frame buffer sizes (at the normal
|
||||
orientation. Each size indicates both the linear physical size of
|
||||
orientation). Each size indicates both the linear physical size of
|
||||
the screen and the pixel size.
|
||||
|
||||
'refresh' is the list of refresh rates for each size. Each element
|
||||
|
|
|
|||
|
|
@ -614,7 +614,7 @@ CreatePicture
|
|||
component-alpha: BOOL
|
||||
|
||||
When used as a source or mask operand, Repeat indicates how the
|
||||
drawable contents should be extented in both directions.
|
||||
drawable contents should be extended in both directions.
|
||||
|
||||
The alpha channel of alpha-map is used in place of any alpha channel
|
||||
contained within the drawable for all rendering operations. The
|
||||
|
|
|
|||
|
|
@ -167,7 +167,7 @@
|
|||
This extension models video monitor capabilities in the X Window
|
||||
System. Some advanced monitors support the simultaneous display
|
||||
of multiple video signals (into separate windows), and that is
|
||||
prepresented here through the ability to display video from
|
||||
represented here through the ability to display video from
|
||||
multiple video input adaptors into X drawables.
|
||||
|
||||
Some monitors support multiple video encodings (mostly for
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue