coder543 at gmail.com
Thu Sep 22 17:25:06 PDT 2011
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.
And seriously. Spitzak. It does not matter which one is doing what. Client
side, compositor side, as long as the code is written *correctly*, 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.
There is *no* 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.
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 *years*. They all
draw to a buffer. Otherwise their contents would always be on top, even if
they should be in the background.
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.
On Thu, Sep 22, 2011 at 6:55 PM, William Swanson <swansontec at gmail.com>wrote:
> On Thu, Sep 22, 2011 at 3:22 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> > That copied the buffer, thus all the drawing was done by the compositor,
> > of course it works. What is needed is a method such that either both draw
> > into the same buffer or the compositor composites the two images
> I think we are misunderstanding each other. The pseudo-code
> "copy_buffer" method performs the final compositing to screen; there
> are no additional copies. Specifically, it alpha-blends
> client-provided shared-memory RGBA window buffer into the final RGB
> desktop buffer that gets swapped directly to screen. Clients aren't
> directly rendering to screen, so this blending is the whole point of
> even having a compositor.
> In my pseudocode, the compositor draws the window border directly into
> the final composited desktop without "storing" it anywhere. In other
> words, the compositor might have to re-draw the window borders up to
> 60 times per second if that's how fast the desktop is changing. This
> should be no more resource intensive than normal compositing,
> especially if the various elements like widgets and title text are
> pre-cached as textures and simply blended together on the GPU. Compiz
> and Emerald prove that compositors are quite capable of rendering
> complex effects on every frame.
> > There is additional latency in that the compositor cannot start drawing
> > border until after the client has drawn the contents. A client could draw
> > the border and contents at the same time (for instance in multiple
> > but also just the setup and teardown of rendering contexts can be shared
> > a single-threaded client).
> Yes, letting the client draw its own border would save the effort of
> re-drawing the border every fame. But then again, re-drawing the
> border every frame should be no more effort than normal compositing.
> Maybe the additional texture loads in the border-drawing code add a
> slight performance hit.
> > The blurry pixels do not have to be in the buffer, therefore they can be
> > generated by the compositor and the client can still draw the
> > partially-transparent border. This is in fact how Windows works. On the
> > modern machines the graphics processor can directly blur sections of the
> > composited image before another image is composited atop.
> I agree that this works, but see how the compositor is now involved in
> doing border-esque stuff (blurring pixels)?
> As I said in the last email, I still don't know whether or not letting
> the compositor render the borders is a good idea. One way lets you
> have client innovations like Google Chrome, and the other way allows
> you to have compositor innovations like XMonad. The performance and
> latency will be roughly the same either way, so there is no technical
> argument for one vs the other.
> Even if the compositor draws the window borders, for example, a
> non-responsive window still won't resize properly. The compositor sees
> the drag and informs the client, "You should resize yourself." Until
> the client responds with a new buffer, however, the compositor is
> stuck drawing the window border in the same non-resized location
> (otherwise it would tear). Thus, compositor-side borders behave no
> better than client-side borders, and a lot of the arguments in favor
> of compositor-side borders still make no sense.
> -William Swanson
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel