On 02/26/2013 01:01 PM, Owen Taylor wrote:
Sorry for joining the discussion late here. I went through the specs and
discussion and have various comments and questions.
- Owen
* It would be great if we could figure out a plan to get to the
point where the exact same application code is going to work for
proprietary and open source drivers. When you get down to the details
of swap this isn't close to the case currently.
- Because swap handled client side in some drivers, INTEL_swap_event
is seen as awkward to implement.
- There is divergence on some basic behaviors, e.g., whether
glXSwapBuffers() glFinish() waits for the swap to complete or not.
- When rendering with a compositor, the X server is innocent of
relevant information about timing and when the application should
draw additional new frames. I've been working on handing this
via client <=> compositor protocols
(https://mail.gnome.org/archives/wm-spec-list/2013-January/msg00000.html)
But this adds a lot of complexity to the minimal client, especially
when a client wants to work both redirected and unredirected.
I think it would be great if we could sit down and figure out what
the Linux-ecosystem API is for this in a way we could give to
application authors.
* One significant problem that I have currently is that the default mode
for the Intel drivers is to use triple buffering and send back swap
events *when rendering the next frame would not block* - that is,
immediately. This results in a frame of unnecessary latency.
(The too-early events are also missing ust/msc/sbc information.)
So I'd like to make sure that we know exactly what SwapComplete means
and not have creative reinterpretations based on what works well
for one client or another.
The SwapComplete event is specified as - "This event is delivered
when a SwapRegion operation completes" - but the specification
of SwapRegion itself is fuzzy enough that I'm unclear exactly what
that means.
- The description SwapRegion needs to define "swap" since the
operation has only a vague resemblance to the English-language
meaning of "swap".
Maybe call it PresentRegion instead? Swap is another one of those
overloaded terms in graphics. It's not quite as bad as "normal," but
it's pretty close.
- My interpretation of SwapRegion is that the actual propagation of
source to destination is *asynchronous* to the X protocol stream.
This is implied by "Schedule a swap..." but probably should be
explicitly stated, since it is radically different from other
rendering in X.
- Is the serial in the SwapComplete event synchronous to the protocol
stream? E.g., can you assume that any CopyArea from the destination
drawable before that serial will get the old contents, and a
CopyArea from the destination after that serial will get the new
contents?
- What happens when multiple SwapRegion requests are made with a
swap-interval of zero. Are previous ones discarded?
- Is it an error to render to a non-idle pixmap? Is it an error to
pass a non-idle pixmap as the source to SwapRegion?
- What's the interaction between swap-interval and target-msc, etc?
- When a window is redirected, what's the interpretation of
swap-interval, target-msc, etc? Is it that the server performs the
operation at the selected blanking interval (as if they window
wasn't redirected), and then damage/other events are generated
and the server picks it up and renders to the real front buffer
at the next opportunity - usually a frame later.
* Do I understand correctly that the idle pixmaps returned from
a SwapRegion request are the pixmaps that *will* be idle once the
corresponding SwapComplete event is received?
If this is correct, what happens if things change before the swap
actually happens and what was scheduled as a swap ends up being
a copy? Is it sufficient to assume that a ConfigureNotify on a
destination window means that all pixmaps passed to previous
SwapRegion requests are now idle?
* In the definition of SWAPIDLE you say:
If valid is TRUE, swap-hi/swap-lo form a 64-bit
swap count value from the SwapRegion request which matches the
data that the pixmap currently contains
If I'm not misunderstanding things, this is a confusing statement
because, leaving aside damage to the front buffer, pixmaps always
contain the same contents (whatever the client rendered into it.)
Is the use of the swap-hi/swap-lo identify the SwapRegion problematical
in the case where swaps aren't throttled? Would it be better to use
sequence number of the request? Or is the pixmap itself sufficient?
* What control, if any, will applications have over the number of
buffers used - what the behavior will be when an application starts
rendering another frame in terms of allocating a new buffer versus
swapping?
* Do we need to deal with stereo as part of this?
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
