Kai-Uwe Behrmann wrote:
However, we had seen quite some objections around subwindows at that
time.
Did something substancial change on that matter?
I don't see anything there that applies to Wayland. The link to the
original proposal is also dead.
the old thread starter from Tomas for refere
On Tue, Dec 18, 2012 at 10:45 AM, Kai-Uwe Behrmann wrote:
Am 17.12.2012 16:47, schrieb Richard Hughes:
On 5 December 2012 14:32, Pekka Paalanen wrote:
One of the most important use cases is a video player in a window. It
has XRGB or ARGB window decorations, usually the video content in YUV,
Am 18.12.2012 06:40, schrieb Bill Spitzak:
On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
Then a client such as gimp could draw all it's display into a single buffer.
To get the different color correction of the center display, it would
declare a subsurface containing this and set it's c
On Tue, Dec 18, 2012 at 10:29 AM, Pekka Paalanen wrote:
> On Mon, 17 Dec 2012 15:47:43 +
> Richard Hughes wrote:
>
>> On 5 December 2012 14:32, Pekka Paalanen wrote:
>> > One of the most important use cases is a video player in a window. It
>> > has XRGB or ARGB window decorations, usually t
On Tue, Dec 18, 2012 at 2:59 PM, John Kåre Alsaker
wrote:
> On Tue, Dec 18, 2012 at 6:40 AM, Bill Spitzak wrote:
>>
>> On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>>
>>
>> Then a client such as gimp could draw all it's display into a single buffer.
>>
>> To get the different color corre
On Tue, Dec 18, 2012 at 6:40 AM, Bill Spitzak wrote:
>
> On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>
>
> Then a client such as gimp could draw all it's display into a single buffer.
>
> To get the different color correction of the center display, it would
>
> declare a subsurface conta
Am 17.12.2012 16:47, schrieb Richard Hughes:
On 5 December 2012 14:32, Pekka Paalanen wrote:
One of the most important use cases is a video player in a window. It
has XRGB or ARGB window decorations, usually the video content in YUV,
and possibly an ARGB overlay for subtitles etc. Currently, th
On Mon, 17 Dec 2012 15:47:43 +
Richard Hughes wrote:
> On 5 December 2012 14:32, Pekka Paalanen wrote:
> > One of the most important use cases is a video player in a window. It
> > has XRGB or ARGB window decorations, usually the video content in YUV,
> > and possibly an ARGB overlay for sub
On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>>
>> Then a client such as gimp could draw all it's display into a single buffer.
>> To get the different color correction of the center display, it would
>> declare a subsurface containing this and set it's color correction
>> differently us
On Mon, Dec 17, 2012 at 11:40 PM, Bill Spitzak wrote:
> That brings up an interesting possibility: can a subsurface (or any surface)
> image be a subrectangle of an image used for another surface? I'm thinking
> this would be possible, provided the client can tell the wayland server to
> use an ar
That brings up an interesting possibility: can a subsurface (or any
surface) image be a subrectangle of an image used for another surface?
I'm thinking this would be possible, provided the client can tell the
wayland server to use an arbitrary stride between rows.
Then a client such as gimp co
On 5 December 2012 14:32, Pekka Paalanen wrote:
> One of the most important use cases is a video player in a window. It
> has XRGB or ARGB window decorations, usually the video content in YUV,
> and possibly an ARGB overlay for subtitles etc. Currently, the client
> has to color-convert the video,
On 12/14/2012 12:29 AM, John Kåre Alsaker wrote:
> On Thu, Dec 13, 2012 at 11:47 PM, Bill Spitzak wrote:
>
>> It will also force the floating
>> window api to allow the client to be in final control of the stacking order,
>> a deficiency in all existing window systems.
> Do you have an example of
On Thu, 13 Dec 2012 12:33:33 -0500
Kristian Høgsberg wrote:
> On Thu, Dec 13, 2012 at 04:07:44PM +0100, John Kåre Alsaker wrote:
> >
> > On Thu, Dec 13, 2012 at 3:30 PM, Pekka Paalanen wrote:
> > >
> > > On Thu, 13 Dec 2012 14:51:17 +0100
> > > John Kåre Alsaker wrote:
> > >
> > >> I see that
On Thu, 13 Dec 2012 14:47:57 -0800
Bill Spitzak wrote:
> FLOATING WINDOWS:
>
> PLEASE consider reusing this code for "floating windows". THEY ARE THE
> SAME THING!!! The only difference is that the compositor can insert
> other surfaces between floating children and the parent.
>
> This would
John Kåre Alsaker wrote:
On Thu, Dec 13, 2012 at 11:47 PM, Bill Spitzak wrote:
I see no reason for extra objects. What I would do is add a "parent" to the
normal surface. If it is NULL then it is a "main" surface. If it points at
another surface then it is a subsurface or a floating window. T
On Thu, Dec 13, 2012 at 11:47 PM, Bill Spitzak wrote:
> I see no reason for extra objects. What I would do is add a "parent" to the
> normal surface. If it is NULL then it is a "main" surface. If it points at
> another surface then it is a subsurface or a floating window. The "parent"
> can be cha
I see no reason for extra objects. What I would do is add a "parent" to
the normal surface. If it is NULL then it is a "main" surface. If it
points at another surface then it is a subsurface or a floating window.
The "parent" can be changed arbitrarily. We must be able to change an
existing sur
On Thu, Dec 13, 2012 at 04:07:44PM +0100, John Kåre Alsaker wrote:
> I added buffered commit_surface in wl_surface_group, which allows
> clients to atomically update the surfaces of their choice. This way we
> don't have to change wl_surface.commit. We can also update the main or
> parent surface a
I added buffered commit_surface in wl_surface_group, which allows
clients to atomically update the surfaces of their choice. This way we
don't have to change wl_surface.commit. We can also update the main or
parent surface and subsurfaces independently.
Hi John,
On Thu, 13 Dec 2012 14:51:17 +0100
John Kåre Alsaker wrote:
> Here is my "subsurface" proposal. I don't like video sinks (or other
> things) running on an independent framerate. I don't want to maintain
> more state in the compositor side for them or have increased
> complexity in the
Here is my "subsurface" proposal. I don't like video sinks (or other
things) running on an independent framerate. I don't want to maintain
more state in the compositor side for them or have increased
complexity in the protocol. They are inefficient and can be solved by
a number of other ways. In th
On Wed, 12 Dec 2012 14:22:49 +
Daniel Stone wrote:
> Hi,
>
> On 6 December 2012 01:32, Pekka Paalanen wrote:
>
> > Clipping
> >
> > The term sub-surface sounds like a sub-window, which may cause one to
> > think, that it will be clipped to the parent surface area. I do not
> > think we sho
Hi,
On 6 December 2012 01:32, Pekka Paalanen wrote:
> Clipping
>
> The term sub-surface sounds like a sub-window, which may cause one to
> think, that it will be clipped to the parent surface area. I do not
> think we should force or even allow such clipping.
>
> Forcing the clipping would waste
Hi,
On 6 December 2012 04:43, Tiago Vignatti wrote:
> indeed. On my "less intrusive" draft of subsurface, I've first started
> brainstorming the input focus behavior [0]. That's quite useful for the
> video player example that wants some kind of input control or a dialog
> stick window that might
On 12/07/2012 06:39 AM, Kristian Høgsberg wrote:
On Fri, Dec 07, 2012 at 01:07:33PM +0200, Pekka Paalanen wrote:
On Fri, 7 Dec 2012 12:34:46 +0200
Pekka Paalanen wrote:
On Wed, 05 Dec 2012 22:45:14 -0800
Bill Spitzak wrote:
Committing changes
I think it may work that a commit on a parent
On Fri, Dec 07, 2012 at 01:07:33PM +0200, Pekka Paalanen wrote:
> On Fri, 7 Dec 2012 12:34:46 +0200
> Pekka Paalanen wrote:
>
> > On Wed, 05 Dec 2012 22:45:14 -0800
> > Bill Spitzak wrote:
> >
> > > > Committing changes
> > >
> > > I think it may work that a commit on a parent is an implied co
On Fri, Dec 07, 2012 at 10:31:20AM +0200, Pekka Paalanen wrote:
> On Wed, 05 Dec 2012 15:43:18 -0200
> Tiago Vignatti wrote:
>
> > Hi,
> >
> > On 12/05/2012 12:32 PM, Pekka Paalanen wrote:
> > >
> > > I have not even thought about sub-surfaces' implications to input
> > > handling or the shell y
On Fri, 7 Dec 2012 12:34:46 +0200
Pekka Paalanen wrote:
> On Wed, 05 Dec 2012 22:45:14 -0800
> Bill Spitzak wrote:
>
> > > Committing changes
> >
> > I think it may work that a commit on a parent is an implied commit on
> > all the children. To make a set of child surfaces all resize in uniso
On Wed, 05 Dec 2012 22:45:14 -0800
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > I am currently looking into sub-surfaces, first to sketch the protocol
> > extension, and I have some open questions. I decided to write an
> > exhaustive document, so we would all be on the same page, and also
On Wed, 05 Dec 2012 15:43:18 -0200
Tiago Vignatti wrote:
> Hi,
>
> On 12/05/2012 12:32 PM, Pekka Paalanen wrote:
> >
> > I have not even thought about sub-surfaces' implications to input
> > handling or the shell yet. Sub-surfaces probably need to be able to
> > receive input. The shell perhaps
Pekka Paalanen wrote:
I am currently looking into sub-surfaces, first to sketch the protocol
extension, and I have some open questions. I decided to write an
exhaustive document, so we would all be on the same page, and also to
clarify my own thoughts.
Glad to see this is being worked on. I ha
Hi,
On 12/05/2012 12:32 PM, Pekka Paalanen wrote:
I have not even thought about sub-surfaces' implications to input
handling or the shell yet. Sub-surfaces probably need to be able to
receive input. The shell perhaps needs a bounding box of the set of
surfaces to be able to pick an initial posi
33 matches
Mail list logo
