In Haiku OS, there is a separate thread for window content versus input response, so its (theoretically) impossible to make an applications completely nonresponsive. It should always at least be able to resize. I would love to see this set as the standard model in Wayland, even if compatibility with existing apps means allowing the current model to function as well.<div>
<br></div><div>And seriously. Spitzak. It does not matter which one is doing what. Client side, compositor side, as long as the code is written <i>correctly</i>, it will behave seamlessly to the user. I don't have problems with Xorg's way of going about things on my machines, whether its my netbook or my overpowerful desktop. It works, and works excellently. A few years ago, not so much. But it could be better, and that's what Wayland is here for. I would actually prefer the compositor to have complete control of the window borders, so that we can move out of the 90's style opaque, unblurred window borders. Blurred glass may not be the definition of good aesthetics, but if we are incapable of such effects, then we cannot innovate beyond them very easily.</div>
<div><br></div><div>There is <b>no</b> technical reason for having the client's do their own decoration these days. You know what's even faster than a client drawing its own decorations? Yeah. The compositor drawing the client's decorations. Why? because while the app is busy loading itself up, pausing for disk i/o or considering the weather outside, whatever it's up to, the compositor can draw a border around the window dimensions that are specified. Instantly. The next frame. Current frame + 1.. The client would be hard pressed to beat that. In fact, if the compositor was feeling up to it, it could draw a launch image inside the window's borders. Whether it's just a generic set of gradients with an elegant loading image in the middle, or a client specified launch image. The client is busy. The client doesn't need to worry about these kinds of things. It's worried about getting up and running before the user walks away. That should be its sole focus.</div>
<div><br></div><div>Latency. What latency? The client can literally draw directly into a buffer that the compositor can copy and paste directly onto the screen. Its not a circular action. The compositor isn't just sitting there having coffee with its client and passing the time with good conversation. The compositor is just drawing a frame around the pasted buffer. We haven't let apps on ANY operating system draw directly to pixels on the screen in <i>years</i>. They all draw to a buffer. Otherwise their contents would always be on top, even if they should be in the background.</div>
<div><br></div><div>Obviously, I'm pro-compositor, but there is enough reasoning on both sides of the argument to take them both into consideration. Latency, sluggishness, and synchronicity are not concerns for either side.</div>
<div><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 6:55 PM, William Swanson <span dir="ltr"><<a href="mailto:swansontec@gmail.com">swansontec@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Sep 22, 2011 at 3:22 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> That copied the buffer, thus all the drawing was done by the compositor, so<br>
> of course it works. What is needed is a method such that either both draw<br>
> into the same buffer or the compositor composites the two images together.<br>
<br>
</div>I think we are misunderstanding each other. The pseudo-code<br>
"copy_buffer" method performs the final compositing to screen; there<br>
are no additional copies. Specifically, it alpha-blends<br>
client-provided shared-memory RGBA window buffer into the final RGB<br>
desktop buffer that gets swapped directly to screen. Clients aren't<br>
directly rendering to screen, so this blending is the whole point of<br>
even having a compositor.<br>
<br>
In my pseudocode, the compositor draws the window border directly into<br>
the final composited desktop without "storing" it anywhere. In other<br>
words, the compositor might have to re-draw the window borders up to<br>
60 times per second if that's how fast the desktop is changing. This<br>
should be no more resource intensive than normal compositing,<br>
especially if the various elements like widgets and title text are<br>
pre-cached as textures and simply blended together on the GPU. Compiz<br>
and Emerald prove that compositors are quite capable of rendering<br>
complex effects on every frame.<br>
<br>
> There is additional latency in that the compositor cannot start drawing the<br>
> border until after the client has drawn the contents. A client could draw<br>
> the border and contents at the same time (for instance in multiple threads,<br>
> but also just the setup and teardown of rendering contexts can be shared in<br>
> a single-threaded client).<br>
<br>
Yes, letting the client draw its own border would save the effort of<br>
re-drawing the border every fame. But then again, re-drawing the<br>
border every frame should be no more effort than normal compositing.<br>
Maybe the additional texture loads in the border-drawing code add a<br>
slight performance hit.<br>
<br>
> The blurry pixels do not have to be in the buffer, therefore they can be<br>
> generated by the compositor and the client can still draw the<br>
> partially-transparent border. This is in fact how Windows works. On the<br>
> modern machines the graphics processor can directly blur sections of the<br>
> composited image before another image is composited atop.<br>
<br>
I agree that this works, but see how the compositor is now involved in<br>
doing border-esque stuff (blurring pixels)?<br>
<br>
As I said in the last email, I still don't know whether or not letting<br>
the compositor render the borders is a good idea. One way lets you<br>
have client innovations like Google Chrome, and the other way allows<br>
you to have compositor innovations like XMonad. The performance and<br>
latency will be roughly the same either way, so there is no technical<br>
argument for one vs the other.<br>
<br>
Even if the compositor draws the window borders, for example, a<br>
non-responsive window still won't resize properly. The compositor sees<br>
the drag and informs the client, "You should resize yourself." Until<br>
the client responds with a new buffer, however, the compositor is<br>
stuck drawing the window border in the same non-resized location<br>
(otherwise it would tear). Thus, compositor-side borders behave no<br>
better than client-side borders, and a lot of the arguments in favor<br>
of compositor-side borders still make no sense.<br>
<font color="#888888"><br>
-William Swanson<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Sincerely,<br> Josh<br>
</div>