The linked document pretty clearly indicates that you can just extend
the blurry render further into the window. There are only 4 parameters
to set the margin thickness, yet the demo program draws a more complex
rendering where the resulting shape two rectangular opaque areas. This
is entirely
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
dr
On Fri, Sep 23, 2011 at 6:33 AM, Bill Spitzak wrote:
> William Swanson wrote:
>
>> draw_compositor_frame()
>> {
>> foreach (window in windows) {
>> copy_buffer(window.buffer, window.x, window.y, window.w, window.h);
>> if (window.needs_border)
>> draw_border(window.x - 8, window.y - 24, w
In Haiku OS, there is a separate thread for window content versus input
response, so its (theoretically) impossible to make an applications
completely nonresponsive. It should always at least be able to resize. I
would love to see this set as the standard model in Wayland, even if
compatibility wit
On Thu, Sep 22, 2011 at 3:22 PM, Bill Spitzak wrote:
> That copied the buffer, thus all the drawing was done by the compositor, so
> of course it works. What is needed is a method such that either both draw
> into the same buffer or the compositor composites the two images together.
I think we ar
William Swanson wrote:
draw_compositor_frame()
{
foreach (window in windows) {
copy_buffer(window.buffer, window.x, window.y, window.w, window.h);
if (window.needs_border)
draw_border(window.x - 8, window.y - 24, window.w + 20, window.h + 32);
}
}
That copied the buffer, thus all
2011/9/22 Bill Spitzak :
> It is IMPOSSIBLE to
> synchronize the drawing of the contents with the border unless they are
> drawn by the same process, and I do wish the people who keep suggesting
> elaborate many-round-trip sync protocols where they keep adding more and
> more steps and latency will
If the client does not respond to events in a reasonable amount of time
the compositor can assume it is dead and do the window manipulation
directly. Resize is not done (though the compositor could simulate it
with scales or clipping/padding of the window).
Nothing stops a toolkit from using m
There is a concern that a malicious user-space program can cause
trouble, such as covering the screen with it's window, taking all the
events, or pretending to be a system service such as a request for the
sudo password.
I think Wayland intends for compositors to prevent this, since the
compo
2011/9/22 Sam Spilsbury :
> [...] For
> example, if pages loaded by a webbrowser contained javascript that
> would allow the client window to move around then there is no way to
> guaruntee (unless you were paranoid) that this would not be allowed.
I would expect the web browser to manage what it
2011/9/22 Niklas Höglund :
> I see a lot of discussions on this list about what clients should be
> allowed to do. Is this such a big deal? All software on my Linux
> systems is free software, and if it doesn't behave it can be fixed.
> Any restrictions in what is allowed is bound to stifle innovat
I've got one questions about unresponsive applications.
I'm quite good at punishing computers. I've found that many
applications stop responding when they shouldn't, for example when
accessing the disk (say if I trash the disk a lot doing something else
at the same time).
Last time I read about W
I see a lot of discussions on this list about what clients should be
allowed to do. Is this such a big deal? All software on my Linux
systems is free software, and if it doesn't behave it can be fixed.
Any restrictions in what is allowed is bound to stifle innovation in
one way or another.
If I do
13 matches
Mail list logo
