Re: Questions about XPresent
Keith Packard writes: > I got started creating a 'semi-automatic compositing' design where the > compositing manager could tell the X server "Hey, just composite this > window to the screen in the 'obvious' way and don't bother me with the > details". Wouldn't that just be RedirectWindow with automatic updates, except without using CopyArea when the depths are the same and the window is not opaque, instead using CompositePicture with PictOpOver synchronized with vblank? I think it would have to composite the contents of windows underneath too in some cases. There would also have to be a way for clients using visuals with an alpha channels to tell the X server which parts of their windows are opaque, similar to _NET_WM_OPAQUE_REGION in the wm-spec. That sounds surprisingly simple, as long you only "automatically composite" windows whose clip lists are the same as their bounds.
Re: Questions about XPresent
Po Lu writes: > Does that make any sense? I'm thinking of a control flow that looks > like this, when the client draws to the window after a pixmap has been > presented by the compositor: > > Client Server Compositing manager > PresentPixmap > PresentRequest ---> actually takes the pixmap > specified and composites > it to display. Yeah, I've toyed with this design several times and never came up with any solid way to manage pixmap ownership across these boundaries, plus it doesn't really fix the underlying latency issues caused by having three processes involved in showing each frame. I got started creating a 'semi-automatic compositing' design where the compositing manager could tell the X server "Hey, just composite this window to the screen in the 'obvious' way and don't bother me with the details". With that, the X server could be in a position to actually make stuff work like a real window system (iOS, Android, Windows, Mac OS X all work this way). You'd turn it off when there was any funny business going on, but most of the time, things could go through this fast path. -- -keith signature.asc Description: PGP signature
Re: Questions about XPresent
Michel Dänzer writes: > I'm thinking of this kind of scenario with a direct rendering compositor: > > 1. Compositor retrieves window pixmap, creates OpenGL texture object for it. > 2. Client sends PresentPixmap request, which results in replacing the window > pixmap. > 3. Client starts drawing new frame to the old window pixmap buffer. > 4. Compositor samples from texture object created in step 1. > > > I did actually try this a while ago, and saw artifacts due to this issue. Hmm, okay. I don't want to work out yet another ugly synchronization protocol, so how about this: the compositing manager makes a new "CompositeRedirectSubwindowPresentation" request on the root window, and receives every PresentPixmap request made by clients to a subwindow of the root window. It must then present the pixmap and send completion/idle notify events itself. That being said, there are definitely more details to work out here. For example, as I said earlier, what if a client draws to the window after PresentCompleteNotify? In that case, a damage notification will be generated, but the drawing will probably have been done to outdated display contents, so the compositor must also tell the X server the the pixmap that was presented in order for future drawing to work correctly. Does that make any sense? I'm thinking of a control flow that looks like this, when the client draws to the window after a pixmap has been presented by the compositor: Client Server Compositing manager PresentPixmap > PresentRequest ---> actually takes the pixmap specified and composites it to display. (window damage between PresentRequest and PresentCompleteNotify is ignored by the compositor.) SetPresentedPixmap <--- compositing manager completes PresentCompleteNotify <- presentation by "flipping". XDrawRectangle > X server copies from the presented pixmap to the window's off screen storage, and then draws the rectangle > DamageNotify PresentIdleNotify <- compositing manager composites the window pixmap and sends PresentIdleNotify for previously flipped pixmap.
Re: Questions about XPresent
On 2022-10-18 16:14, Po Lu wrote: > Michel Dänzer writes: > >> The problem with this is that there's no explicit transfer of >> ownership of the window pixmap between the compositor and other >> entities. So the compositor may end up reading from a stale window >> pixmap after another presentation has already flipped in a new pixmap, >> and the client may already be drawing a new frame to the pixmap used >> by the compositor, resulting in visual artifacts. > > If the compositor issues a Composite request, then by the time the > request arrives on the X server, won't the pixmap resource point to the > data of the pixmap that is currently busy? Or are you saying that the X > server keeps references to pixmap data that it has sent IdleNotify > events for, and may use those pixmaps in response to a future request > from the compositor? I'm thinking of this kind of scenario with a direct rendering compositor: 1. Compositor retrieves window pixmap, creates OpenGL texture object for it. 2. Client sends PresentPixmap request, which results in replacing the window pixmap. 3. Client starts drawing new frame to the old window pixmap buffer. 4. Compositor samples from texture object created in step 1. I did actually try this a while ago, and saw artifacts due to this issue. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Questions about XPresent
Michel Dänzer writes: > You don't need to do anything special. The effect of PresentPixmap is > essentially the same as XCopyArea as far as the destination window > contents are concerned, regardless of how the presentation is > effectively performed. Thanks. > The problem with this is that there's no explicit transfer of > ownership of the window pixmap between the compositor and other > entities. So the compositor may end up reading from a stale window > pixmap after another presentation has already flipped in a new pixmap, > and the client may already be drawing a new frame to the pixmap used > by the compositor, resulting in visual artifacts. If the compositor issues a Composite request, then by the time the request arrives on the X server, won't the pixmap resource point to the data of the pixmap that is currently busy? Or are you saying that the X server keeps references to pixmap data that it has sent IdleNotify events for, and may use those pixmaps in response to a future request from the compositor? Thanks.
Re: Questions about XPresent
On 2022-10-07 09:09, Po Lu wrote: > > The documentation for PresentPixmap says: > > If 'options' contains PresentOptionAsync, and the 'target-msc' > is less than or equal to the current msc for 'window', then > the operation will be performed as soon as possible, not > necessarily waiting for the next vertical blank interval. > > What does the "necessarily" here mean? That the presentation might > still wait for vblank, even if PresentOptionAsync is specified, and the > target MSC is less than the MSC of the window? I think so. However, AFAICT the xserver Present code will always execute the presentation ASAP in this case, never wait for vblank first. > What will a following SyncSetCounter do? Will the counter always be set > to the new value after the presentation happens and the window damage is > sent to the compositor? You mean if the presentation waited for vblank first? If so, I don't see any such implicit synchronization between PresentPixmap and SyncSetCounter (or any other request). > My second question is about drawing to the window after presentation > happens. When direct presentation becomes impossible (by, for example, > the Wayland client attaching a subsurface), then the results of any > previously made presentation must be overwritten by the following > Composite requests. What happens if a Composite request is made, > targeting a window whose contents have been previously specified with > PresentPixmap, especially if the pixmap has been flipped and not copied? > > Do I have to present an empty pixmap, wait for any PresentIdleNotify > for the previously attached pixmap, or what? You don't need to do anything special. The effect of PresentPixmap is essentially the same as XCopyArea as far as the destination window contents are concerned, regardless of how the presentation is effectively performed. > That brings me to the third question. Wouldn't a good optimization be > to "flip" the presented pixmap, if possible, into the contents of the > window pixmap if the window were to be redirected? Compositing managers > would then be able to read from the window immediately after > presentation, without needing the contents of the presented pixmap to be > copied to the window pixmap first. The problem with this is that there's no explicit transfer of ownership of the window pixmap between the compositor and other entities. So the compositor may end up reading from a stale window pixmap after another presentation has already flipped in a new pixmap, and the client may already be drawing a new frame to the pixmap used by the compositor, resulting in visual artifacts. (Xwayland can do essentially what you're describing, since it has an explicit transfer of ownership via Wayland) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
AW: Yet another leak in Xlib
will sombody close the hole in the documentation ? Von: xorg-devel im Auftrag von Po Lu Gesendet: Dienstag, 4. Oktober 2022 04:38 An: Thomas Dickey Cc: xorg-devel@lists.x.org Betreff: Re: Yet another leak in Xlib Thomas Dickey writes: > looks okay reading the library code (src/xlibi18n/XDefaultIMIF.c, _CloseIM). > > xterm doesn't free that 'xim' value (and the XCloseIM manual page doesn't > say who's responsible for that -- though it's possible that some other > application developer read the library source code and is freeing it). XCloseIM (in IMWrap.c) frees the XIM value itself after calling close to deinitialize the input method. So I think the patch should be fine, and I've been running it for a while with no ill effect. Could it be installed? Thanks.
