X11 present #989
X11 present #989
Conversation
|
Only the last buffer gets rendered; the others are discarded. I'll add a
comment where the buffers are defined.
…On Wed, May 27, 2020 at 7:54 AM Kaur Kuut ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In druid-shell/src/platform/x11/window.rs
<#989 (comment)>:
> + window_id,
+ self.width,
+ self.height,
+ );
+ self.all_pixmaps.push(pixmap_id);
+ self.idle_pixmaps.push(pixmap_id);
+ pixmap_id
+ }
+
+ fn create_pixmaps(&mut self, conn: &Rc<Connection>, window_id: u32) {
+ if !self.all_pixmaps.is_empty() {
+ log::error!("BUG: need to free the pixmaps before creating new ones");
+ self.free_pixmaps(conn);
+ }
+
+ // Two buffers is probably enough. We'll create more on demand.
Okay, then my question would be - are these additional buffers additive or
replacements?
So if we have say 10 buffers and we instruct X to render all of these in a
row. Does only the last one get rendered, or does this manifest as a 10
frame delay?
If it's extra delay, then we should attempt an optimization solution. If
just the last one gets used, then we should add a comment stating that
these extra buffers wont cause actual delays.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#989 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALBRMJWRYRAIERVAFQLB3TRTUERBANCNFSM4NJ6QT4A>
.
|
|
I'd like to make progress on this, but I'm blocked by some showstoppers in Is there a good way of making progress there? |
|
This might be interesting: |
|
Hm, yeah. I had a quick look at the docs and they look pretty good (well, the auto-generated code for the extensions is missing docs, but that's not too bad). One downside is that it's fairly new and doesn't have any substantial users on crates.io. It would also add dependencies on |
|
I never saw anything using the present extension, I think... I kind of expected that one just uses a timer and schedules redraws internally while animations are running. I did not look at anything in here, but what exactly do you need present for? Things usually use gl when they want vsync'd drawing. |
| let region_id = conn.generate_id(); | ||
|
|
||
| if let Err(e) = | ||
| xcb::xfixes::create_region_checked(&conn, region_id, &[]).request_check() |
There was a problem hiding this comment.
This doesn't seem like an error worth handling (i.e.: Why not use the unchecked variant?). Creating an empty region should never fail, I think. Unless something is out of memory and we have more serious problems than Present support.
There was a problem hiding this comment.
Creating an empty region should never fail
That's great until it does. Especially given how much diversity there is in Linux-land with implementations. This check isn't really in a hot path, so being more defensive is fine I think.
There was a problem hiding this comment.
The general error-handling approach I'm using (which I guess should be written in a comment) is to check everything synchronously when initializing, and then after that to collect errors asynchronously through the event loop.
The main reason is for vsync, yes. The two options for vsync seem to be present and gl, and present is easier 😄 I found some examples of window managers using present -- they seem to usually have a present path and a gl path, and I just decided to try the present one first. I was also hoping that present might improve latency (and in particular, give us explicit control over latency). This is more speculative, though, and I don't currently have any way to measure it anyway. |
|
Resurrecting this now that #1025 is in.
|
xStrom
added
S-waiting-on-author
|
Ok, I think this is in better shape now. In addition to using the present extension, this also improves the non-present path a little, by drawing into a pixmap and then copying out those pixels. (We use the same pixmap-handling code in both paths; the only difference is whether we present or copy.) I've tested this in several different configurations, and it seems to work without tearing and with very few missed frames. Funny story: I discovered while testing this that my laptop was using generic video drivers, because I never installed the intel ones 😐 . (I did see some tearing with the generic drivers, but they went away with the intel ones.) I also tested on nouveau drivers. |
luleyleo
added
S-needs-review
luleyleo
added
S-waiting-on-author
Co-authored-by: Leopold Luley <[email protected]>
Co-authored-by: Leopold Luley <[email protected]>
Co-authored-by: Leopold Luley <[email protected]>
Co-authored-by: Leopold Luley <[email protected]>
|
Seems to be a problem with piet-coregraphics? I'll just wait a bit and see if it gets better... |
jneem
added
S-needs-review
Fixes #932
This adds support for the X11 Present extension, for scheduling drawing, falling back to the old sleep-based method if Present is absent or causes errors.
The main showstopper for now is a bug in rust-xcb that breaks the present extension. Unfortunately, that project doesn't seem very active -- I see that @xStrom has a PR that's been sitting for a while...