[PATCH 2/2 weston] toytoolkit: Don't draw shadows for maximized windows.
spitzak at gmail.com
Mon Aug 13 09:54:28 PDT 2012
Scott Moreau wrote:
> 1. The "content" region. This is the part of the window that does
> not include the "edges". However it *does* include the titlebar.
> Imagine the "part of the window you see when it is maximized". This
> is different and smaller than the input region
> No it isn't. The input region and your theoretical content region are
> exactly the same.
The input region includes the window edges, which is outside the region
I am talking about.
There may be a failure to understand exactly what pixels I am talking
about. Lets zoom way in on the right edge of a Windows95-style window
which is filled with solid green. Here are the (approximate) colors of
the right 4 pixels:
green light-gray darker-gray black
The green pixel is inside my proposed region. The light and dark gray
pixels are inside the input region (because the user can click on them
to resize the window). Thus my region is smaller than the input region.
(The black pixel probably is inside the input region as well, though I
think it should be outside to properly get snap-to-outside-edge
behavior, it can be considered a very dense shadow).
If you maximize the window, you can see that my region is what is lined
up with the edges of the output and with any panels around the screen.
Thus this region has meaning. A "maximized" bit is insufficient as it
does not describe other states such as maximized-vertically.
> and should be specified by clients using a new api very similar to
> how the input and opaque regions are specified. Shells need this
> information to property implement snap-to-edge (where the edge is of
> another window, a panel, or an output),
> No it doesn't. We can do snap-to-edge for any edge with the input and
> surface areas known already.
You can only snap to the *OUTSIDE* of the edge. There is no indication
as to where the inside of the edge is. This information is needed to get
proper snap to inside edge and to snap windows to each other or behind
> 2. When the shell tells a client to configure a window, it should
> communicate both a size for the surface image, and the bounding box
> of the content region in this new size.
> It already does this and it's called the input region.
Sorry, I do not see any shell event saying what the input region size
should be. The client can tell the shell, but not the other way around.
If this was added it would work, though it has the unfortunate fact that
it would have a negative top-left corner for a maximized window. That is
why I would prefer that the shell communicate the contents region.
It does not remove the need for the shell to know the contents region,
since the shell cannot correctly do snap to inside edges without it.
> To make your point more specific, why not submit a patch implementing
> what you think should happen? I'm not really sure why you're doing this
> whole write up without any code to show.
I have been trying for a few months to successfully compile Wayland. It
used to work but has failed ever since the api freeze. I did upgrade the
machines being used to the newest Ubuntu but this hardly made things better.
At the moment the display I have is skewed unless the surfaces are a
multiple of 16 pixels wide. It is obvious that some stride requirement
is not being communicated correctly from the driver to the client, but I
did not want to annoy the list until I tried to figure out how this
information should be sent.
It also is dreadfully slow because, despite changes to the driver and 2
updates to the entire os, and changing the window manager to 4 different
ones (both compositing and non-compositing), and following suggestions
that I alter compositing settings) I still have the problem that
x11_compositor only sees one event and then insists on redrawing the
screen. Does anybody else have this problem?
More information about the wayland-devel