As far as I can tell, the main problem with server side decoration is that applications cannot modify them and thus they create their own decoration. Please correct me if I'm wrong.<br>So why can't we enforce the WM to provide an API for modifying the decorations? If a WM wouldn't implement it, we'd use some default decoration for applications that need to use the API. Chrome could for example get a surface to draw its tabs from KWin, and KWin would ensure the tabs don't overlap with the buttons, etc.<br>I hope this wasn't proposed in the thousands of CSD posts before ;)<br><br>André<br><br><div id="htc_header" style="">----- Reply message -----<br>Von: "Peng Huang" <shawn.p.huang@gmail.com><br>Datum: So., Mai. 8, 2011 04:58<br>Betreff: client side decorations<br>An: "Mike Paquette" <paquette.mj@gmail.com><br>Cc: "Kristian Høgsberg" <krh@bitplanet.net>, "Sam Spilsbury" <smspillaz@gmail.com>, "wayland" <wayland-devel@lists.freedesktop.org>, <maltee@lavabit.com>, "Bill Spitzak" <spitzak@gmail.com>, "microcai" <microcai@fedoraproject.org><br><br><br></div><br><br><div class="gmail_quote">On Sat, May 7, 2011 at 12:30 PM, Mike Paquette <span dir="ltr"><<a href="mailto:paquette.mj@gmail.com">paquette.mj@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"><br>
On May 7, 2011, at 8:40 AM, microcai wrote:<br>
<br>
>> I know some basic theory of compositor. But I still have concern about<br>
>> client window decorations. I think it is very likely an application<br>
>> becomes unresponsive during resizing. Or a user tires to resize a<br>
>> unresponsive window. In that case, I don't know if compositor can draw an<br>
>> updated title bar or just stretch the outdated window context to the new<br>
>> size. At same time how the compositor calculate rectangles' size and<br>
>> position for title bar and buttons?<br>
>><br>
>> Peng<br>
>><br>
><br>
> Like I said, the compositor can call the client unconditional via<br>
> signal. No matter it is live or dead lock.<br>
<br>
</div>I'm not entirely sure this is a workable idea. Signals are not a reliable inter-process communications mechanism. There are also limits as to what state can be safely modified from within a signal handler. Non-async-signal-safe functions cannot be invoked from a signal handler.. That would include functions that alter graphics state. A normal thread of execution within a client may not be coded to anticipate asynchronous modification of the current graphics state.<br>
<br>
The use of a lock to guard the graphics state is insufficient here. If the graphics state is guarded by a lock, common when multiple asynchronous threads are sharing a graphics state, then the signal handler must also honor that lock. This can lead to a contention problem should the signal handler be invoked on the thread already holding the lock.<br>
<br>
An application becoming unresponsive during app window resizing is an application design problem, and is best addressed at the application level, not as pat of the window server and compositor design. The window server design should provide mechanisms, but strive to be as free of policy as possible. Usability issues such as an unresponsive application are better handled as part of the user interface policy mechanisms, implemented as part of the toolkits and desktop management logic.<br>
</blockquote><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">I think when the system has high work load, and user try to resize an application, it is very likely the application will become unresponsive for several seconds (because high CPU load or need read some memory pages from swap). In this case, I don't know what will be the user experience of wayland. The user can not resize the application at all, or user can resize it, but the decoration and window context is outdated. In current X system, at least the decoration is updated and clickable.</div>
<div><br></div><div>In another case. I find many applications which do some synchronized work (writing or downloading file, updating package, encoding, rendering and etc) in ui thread. That causes ui unresponsive. Although I know it is not good, but it is very easy way for not experienced developers. Writing async or multi-thread code is not easy for everyone. Those applications are not unusual, so wayland should try to provide better UX for them.</div>
<div><br></div><div><br></div><div>At last, I want to ask how wayland draw focused and unfocsed window. If it draws different style decorations for them, it may cause mess when some windows are unresponsive. Probably users will find two focused window or can not find focused window on desktop.</div>
<div> </div><div>Peng</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The window server can provide the mechanisms to move, hide, show, and resize windows. Decisions as to how to handle unresponsive applications and present UI regarding these applications is best done at a higher level.<br>
<font color="#888888"><br>
Mike Paquette</font></blockquote></div><br>