client side decorations

[Peng Huang]

On Sat, May 7, 2011 at 12:30 PM, Mike Paquette <paquette.mj at gmail.com>wrote:

>
> On May 7, 2011, at 8:40 AM, microcai wrote:
>
> >> I know some basic theory of compositor.  But I still have concern about
> >> client window decorations. I think it is very likely an application
> >> becomes unresponsive during resizing. Or a user tires to resize a
> >> unresponsive window. In that case, I don't know if compositor can draw
> an
> >> updated title bar or just stretch the outdated window context to the new
> >> size. At same time how the compositor calculate rectangles' size and
> >> position for title bar and buttons?
> >>
> >> Peng
> >>
> >
> > Like I said, the compositor can call the client unconditional via
> > signal. No matter it is live or dead lock.
>
> 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.
>
> 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.
>
> 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.
>

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.

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.


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.

Peng


>
> 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.
>
> Mike Paquette
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110507/50862f4c/attachment.htm>