Pekka Paalanen wrote:
On Fri, 03 May 2013 12:11:17 -0700
Bill Spitzak wrote:
Pekka Paalanen wrote:
What chip do you have in mind, that can do arbitrary
matrix-based transforms during an overlay scanout?
That just means the surface cannot use the overlay, or the compositor
has to use an in
On Fri, 3 May 2013 19:16:41 +0100
Daniel Stone wrote:
> On 3 May 2013 18:50, Bill Spitzak wrote:
> > Currently one of the things you can do to a wl_surface is that you can find
> > the wl_shell object and ask it to create a wl_shell_surface object given a
> > wl_surface id, and then you can do
On Fri, 03 May 2013 12:11:17 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > What chip do you have in mind, that can do arbitrary
> > matrix-based transforms during an overlay scanout?
>
> That just means the surface cannot use the overlay, or the compositor
> has to use an intermediat
Pekka Paalanen wrote:
What chip do you have in mind, that can do arbitrary
matrix-based transforms during an overlay scanout?
That just means the surface cannot use the overlay, or the compositor
has to use an intermediate image. There are lots of other reasons the
surface does not use the o
Hi,
Again I fear we're drifting massively off-topic, but here we go ...
On 3 May 2013 18:50, Bill Spitzak wrote:
> Daniel Stone wrote:
>> Subsurfaces are being designed for in-process cases, such as a media
>> player inside a browser. Foreign surfaces are intended for
>> cross-process buffer/sur
Daniel Stone wrote:
Subsurfaces are being designed for in-process cases, such as a media
player inside a browser. Foreign surfaces are intended for
cross-process buffer/surface sharing, but I think nested compositors
is actually better for the usecase I had in mind, which is WebKit2.
So it woul
Hi,
On 2 May 2013 20:33, Bill Spitzak wrote:
> Daniel Stone wrote:
>>> I also think all of wl_shell should be a core requirement.
>>
>> Not all compositors are user sessions. Think about nested compositors
>> for browsers, or capture, or also very stripped-down usecases where
>> they really don'
On Thu, 2 May 2013 14:43:38 -0500
Jason Ekstrand wrote:
> On Thu, May 2, 2013 at 1:22 PM, Daniel Stone
> wrote:
>
> > Hi,
> >
> > On 2 May 2013 15:42, Jason Ekstrand wrote:
> > > Ok, I see it now. Sorry, but I missed it on my first
> > > read-through. Yes,
> > it
> > > fixes the problem, but
On Thu, 2 May 2013 09:42:42 -0500
Jason Ekstrand wrote:
> On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen
> wrote:
>
> > On Tue, 30 Apr 2013 10:54:25 -0500
> > Jason Ekstrand wrote:
...
> > > On Tue, Apr 30, 2013 at 2:33 PM, Pekka Paalanen
> > > wrote:
> > >
...
> > > > This interface al
On Thu, 02 May 2013 12:16:23 -0700
Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
> > Agreed. Sending transform matrices or the like has HUGE rounding
> > problems. Particularly when we're using wl_fixed which is 24.8.
> > Other methods would require adding rounding conventions etc.
>
> I was
On Thu, May 2, 2013 at 1:22 PM, Daniel Stone wrote:
> Hi,
>
> On 2 May 2013 15:42, Jason Ekstrand wrote:
> > Ok, I see it now. Sorry, but I missed it on my first read-through. Yes,
> it
> > fixes the problem, but in an extremely confusing way. The reason I say
> it
> > is confusing is because
Daniel Stone wrote:
I also think all of wl_shell should be a core requirement.
Not all compositors are user sessions. Think about nested compositors
for browsers, or capture, or also very stripped-down usecases where
they really don't want to have to deal with this kind of thing.
For simple
Jason Ekstrand wrote:
Agreed. Sending transform matrices or the like has HUGE rounding
problems. Particularly when we're using wl_fixed which is 24.8. Other
methods would require adding rounding conventions etc.
I was assuming IEEE 32-bit floating point would be in the api for at
least th
Hi,
On 2 May 2013 15:42, Jason Ekstrand wrote:
> Ok, I see it now. Sorry, but I missed it on my first read-through. Yes, it
> fixes the problem, but in an extremely confusing way. The reason I say it
> is confusing is because it inherently mixes buffer and surface coordinate
> systems. I reall
Hi,
On 2 May 2013 19:06, Bill Spitzak wrote:
> Pekka Paalanen wrote:
>> So it's really a question whether we can require all compositors to
>> unconditionally support crop&scale. And that really means *all* Wayland
>> compositors forever, since wl_surface is core protocol.
>
> I see no reason not
Pekka Paalanen wrote:
So it's really a question whether we can require all compositors to
unconditionally support crop&scale. And that really means *all* Wayland
compositors forever, since wl_surface is core protocol.
I see no reason not to make this a requirement. You already require 90
degr
On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 10:54:25 -0500
> Jason Ekstrand wrote:
> > On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
> > john.kare.alsa...@gmail.com> wrote:
> > > I'd say we should split the cropping and scaling request into two.
> >
> > How
On Thu, 02 May 2013 10:53:14 +0300
Ander Conselvan de Oliveira wrote:
> The protocol allows us to add new requests to a new version of an
> interface. For instance, the set_buffer_transform request was added
> to version 2 of the wl_surface interface.
>
> I believe the scaled video use case is
On Tue, 30 Apr 2013 15:49:16 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak
> wrote:
>
> > I'm not clear on why Wayland's design requires adding 2 dummy
> > objects to the api (in this case the "wl_scalar" factory and the
> > per-surface "wl_surface_scalar") rather
On Tue, 30 Apr 2013 14:21:41 -0700
Bill Spitzak wrote:
> "scalar" is often used to identify a single number in linear algebra.
> A different name would be better. "transform" might work but that
> also would cover the subsurface and surface transforms, perhaps that
> can be moved to this api as w
On Tue, 30 Apr 2013 10:54:25 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
> john.kare.alsa...@gmail.com> wrote:
>
> > I'd say we should split the cropping and scaling request into two.
> >
>
> How would you suggest doing that? I actually really like the
>
On Tue, 30 Apr 2013 17:08:49 -0400
Matthias Clasen wrote:
> On Tue, Apr 30, 2013 at 8:33 AM, Pekka Paalanen
> wrote:
> > Hi all,
> >
> > below is my first draft for a wl_surface scaling and cropping
> > extension. I called it wl_scaler in the lack of a better name. It is
> > designed similarly t
On Tue, 30 Apr 2013 22:35:22 +0800
Zhi An Ng wrote:
> > I'd like to have a better name for it, and you might want the set
>
> I
> checked up the thesaurus and the closest contender was "size", so I
> guess you already have the best name :)
>
>
> > Comments? Is the language clear?
>
> >
On 05/01/2013 02:16 AM, John Kåre Alsaker wrote:
On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote:
On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak mailto:spit...@gmail.com>> wrote:
I'm not clear on why Wayland's design requires adding 2 dummy
On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak wrote:
>
>> I'm not clear on why Wayland's design requires adding 2 dummy objects to
>> the api (in this case the "wl_scalar" factory and the per-surface
>> "wl_surface_scalar") rather than jus
Pekka Paalanen wrote:
Hi all,
below is my first draft for a wl_surface scaling and cropping
extension. I called it wl_scaler in the lack of a better name. It is
designed similarly to the other wl_surface extensions wl_shell_surface
and wl_subsurface.
There probably isn't any interesting detai
On Tue, Apr 30, 2013 at 8:33 AM, Pekka Paalanen wrote:
> Hi all,
>
> below is my first draft for a wl_surface scaling and cropping
> extension. I called it wl_scaler in the lack of a better name. It is
> designed similarly to the other wl_surface extensions wl_shell_surface
> and wl_subsurface.
>
On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak wrote:
> I'm not clear on why Wayland's design requires adding 2 dummy objects to
> the api (in this case the "wl_scalar" factory and the per-surface
> "wl_surface_scalar") rather than just adding new methods to the wl_surface
> object.
>
> It seems w
Jason Ekstrand wrote:
Can't the client just destroy the scaler?
Good question is whether these sub-objects (or whatever they are called)
should do something when created & destroyed. That does make it harder
to hide their existence and pretend the api is on the parent object.
_
I'm not clear on why Wayland's design requires adding 2 dummy objects to
the api (in this case the "wl_scalar" factory and the per-surface
"wl_surface_scalar") rather than just adding new methods to the
wl_surface object.
It seems wasteful for clients and servers to track this whole
constella
On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
john.kare.alsa...@gmail.com> wrote:
> I'd say we should split the cropping and scaling request into two.
>
How would you suggest doing that? I actually really like the simplicity of
this box maps to that box.
> Specifying a scaling with a NU
> I'd like to have a better name for it, and you might want the set
I
checked up the thesaurus and the closest contender was "size", so I guess
you already have the best name :)
> Comments? Is the language clear?
>
>
Should this simply be called "get"? Since the above request i
I'd say we should split the cropping and scaling request into two.
Specifying a scaling with a NULL buffer should still set the surface size,
so we can have surfaces with only an input region.
I don't see a way to disable scaling and cropping, could passing 0 as width
and height do that?
On Tue
Hi all,
below is my first draft for a wl_surface scaling and cropping
extension. I called it wl_scaler in the lack of a better name. It is
designed similarly to the other wl_surface extensions wl_shell_surface
and wl_subsurface.
There probably isn't any interesting details to debate, right? ;-)
34 matches
Mail list logo
