spitzak at gmail.com
Thu Sep 22 20:12:30 PDT 2011
Sam Spilsbury wrote:
> I won't weigh in in this discussion any further as this topic has been
> discussed to death, but I do want to clarify this - Windows does use
> compositor generated backgrounds and merely allows the client to
> specify which parts they will override drawing and where the client
> drawing in the frame should start . I'm not going to comment on
> whether or not that's better solution than CSD because I do not wish
> to get involved in the debate, but I do wish to clarify that.
>  http://msdn.microsoft.com/en-us/library/ms748975.aspx
By "client" I am including any dll/so/library that is also running in
the address and process space occupied by the application program. That
may be the source of a lot of confusion, including what you are saying.
"client" means everything that happens without a kernel task switch.
What I want is for all the synchronous communicate to be limited as much
as possible to inside the same process and address space, and not have
to use OS api. I realize that to literally follow this rule we are
limited to overlapping windows in the compostor, but as that is still
the primary api, and it does not make tiled windows any worse, I see no
reason to not use csd.
I think if there was a real solution to multiple processes then all the
widgets could be drawn by different processes. There is nothing special
about window borders, your MSDN example shows that they even have
extremely complex borders that the client wants to control.
More information about the wayland-devel