[PATCH 2/2 weston] toytoolkit: Don't draw shadows for maximized windows.

[Scott Moreau]

On Mon, Aug 13, 2012 at 10:54 AM, Bill Spitzak <spitzak at gmail.com> wrote:

> 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.
>

I can't think of a reason why the compositor would need to know this
information. It is most certainly not what you snap to.


>
> 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.


You're using Windows 95 as a base example? First of all, I don't know why
you'd assume that everyone knows how that interface looked. Second, I don't
even want to remember how it looked. Third, we're not trying to recreate
windows starting from '95. I really think this is a very poor choice for an
example.


>
>
>      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
> panels.


No, that's not how this works. Since the client draws it's own decorations,
it will change them based on state. For instance if it's fullscreen, it
draws none. For maximize, it shouldn't draw the shadow border. If it's your
client, you can do whatever; and that's where this needs to happen. The
client draws it's contents and decoration, then tells the compositor what
the input region is. The client can choose to draw anything or set any
input rect it wants to. This is the way it works. We do not need to know
the content area on compositor side.


>
>
>      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.
>

It does not need to go backward.


>
> 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.


Snapping will work fine. You do not snap to the inside edge of the
decoration, you snap to the input region. The client can set the input
region to whatever it wants.


>
>
>  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.
>

It has been building fine here for at least a couple months. You should try
latest with the patches for mesa from here
https://bugs.freedesktop.org/show_bug.cgi?id=52267


>
> 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.
>

You should probably file a bug report about this.


>
> 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?
>

I don't know what you're talking about here but you can try the
show_repaint patch on the list to see if it's actually redrawing what you
think it is.



Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120813/3aa13a4a/attachment-0001.html>