On Thu, 23 May 2013 14:51:16 -0400 (EDT)
Alexander Larsson wrote:
> > What if a client sets scale=0?
>
> I guess we should forbid that, as it risks things dividing by zero.
>
> > Maybe the scale should also be signed here? I think all sizes are
> > signed, too, even though a negative size does
> What if a client sets scale=0?
I guess we should forbid that, as it risks things dividing by zero.
> Maybe the scale should also be signed here? I think all sizes are
> signed, too, even though a negative size does not make sense. We seem
> to have a convention, that numbers you compute with ar
On Wed, 22 May 2013 21:49:25 -0400
Kristian Høgsberg wrote:
> On Mon, May 20, 2013 at 10:49:27AM +0300, Pekka Paalanen wrote:
> > Hi Alexander,
> >
> > nice to see this going forward, and sorry for replying so rarely and
> > late.
> >
> > On Thu, 16 May 2013 15:49:36 +0200
> > al...@redhat.com
On Mon, May 20, 2013 at 10:49:27AM +0300, Pekka Paalanen wrote:
> Hi Alexander,
>
> nice to see this going forward, and sorry for replying so rarely and
> late.
>
> On Thu, 16 May 2013 15:49:36 +0200
> al...@redhat.com wrote:
>
> > From: Alexander Larsson
> >
> > This adds the wl_surface.set_b
On ons, 2013-05-22 at 13:01 +0300, Pekka Paalanen wrote:
> > For the record, Microsoft uses "DIP", for Device-independent-pixels, and
> > Apple uses "Points" for the non-hardware coordinates (in the app level
> > APIs).
>
> And we have no well-known equivalent in the FOSS or Linux world?
Not tha
On Wed, 22 May 2013 11:50:31 +0200
Alexander Larsson wrote:
> On ons, 2013-05-22 at 11:42 +0200, Alexander Larsson wrote:
> > On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote:
>
> > > - wayland units, wu
> > > - wayland pixels, wp, wpx
> > > - surface units, su
> > > - surface unit pixels
On ons, 2013-05-22 at 11:42 +0200, Alexander Larsson wrote:
> On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote:
> > - wayland units, wu
> > - wayland pixels, wp, wpx
> > - surface units, su
> > - surface unit pixels, sux
> > - surface pixels, sp, spx
> > - wayland surface units, wsu
> > - w
On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote:
> On Wed, 22 May 2013 10:12:00 +0200
> Alexander Larsson wrote:
>
> > On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
> >
> > > We use the units of "pixels" in the surface coordinate system, even
> > > if they do not correspond ex
On Wed, 22 May 2013 10:12:00 +0200
Alexander Larsson wrote:
> On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
>
> > We use the units of "pixels" in the surface coordinate system, even
> > if they do not correspond exactly to any "real" pixels like
> > elements in a buffer or on screen.
On ons, 2013-05-22 at 09:11 +0300, Pekka Paalanen wrote:
>
> > What I would like in the end is a per-output slider bar (or something of
> > that ilk) that let's the user select the interface size on that output.
> > Sure, they probably won't be able to select *any* resolution (the
> > compositor
On mån, 2013-05-20 at 13:56 -0500, Jason Ekstrand wrote:
> On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen
> wrote:
> On Thu, 16 May 2013 16:43:52 -0500
> Jason Ekstrand wrote:
>
> > The point of this soi is to allow surfaces to render the
> same size on
>
On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
> On Tue, 21 May 2013 08:35:53 -0700
> Bill Spitzak wrote:
> > This proposal does not actually restrict widget positions or line sizes,
> > since they are drawn by the client at buffer resolution. Although
>
> No, but I expect the toolki
On Mon, 20 May 2013 13:56:27 -0500
Jason Ekstrand wrote:
> On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen wrote:
>
> > On Thu, 16 May 2013 16:43:52 -0500
> > Jason Ekstrand wrote:
> >
> > > The point of this soi is to allow surfaces to render the same size on
> > > different density outputs.
On Tue, 21 May 2013 08:35:53 -0700
Bill Spitzak wrote:
> On 05/20/2013 11:46 PM, Pekka Paalanen wrote:
>
> >> Let's say the output is 10,000dpi and the compositor has set it's scale
> >> to 100. Can a client make a buffer that is 10,050 pixels wide appear 1:1
> >> on the pixels of this output? I
On Tue, May 21, 2013 at 5:35 PM, Bill Spitzak wrote:
>However both proposals have this problem if pre-compositing is not done,
and most practical shells I can figure out can't do pre-compositing because
that requires another buffer for every parent, so maybe this is not a big
deal.
Pre-compositin
On 05/20/2013 11:46 PM, Pekka Paalanen wrote:
Let's say the output is 10,000dpi and the compositor has set it's scale
to 100. Can a client make a buffer that is 10,050 pixels wide appear 1:1
on the pixels of this output? It looks to me like only multiples of 100
are possible.
As far as I under
On Mon, 20 May 2013 17:58:30 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> >> This seems pretty limiting to me. What happens when *all* the outputs
> >> are hi-res? You really think wayland clients should not be able to take
> >> full advantage of this?
> >
> > Then the individual pix
Pekka Paalanen wrote:
This seems pretty limiting to me. What happens when *all* the outputs
are hi-res? You really think wayland clients should not be able to take
full advantage of this?
Then the individual pixels are so small that it won't matter.
It does not matter how tiny the pixels ar
On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen wrote:
> On Thu, 16 May 2013 16:43:52 -0500
> Jason Ekstrand wrote:
>
> > The point of this soi is to allow surfaces to render the same size on
> > different density outputs.
>
> Are you serious? Really? Same size measured in meters?
>
No, measure
On Fri, 17 May 2013 12:06:35 -0700
Bill Spitzak wrote:
> Alexander Larsson wrote:
>
> > You can make a surface of any integer size (and it has to be integer due
> > to existing APIs on surface coordinates/sizes), however the *buffer* has
> > to be an integer multiple of the surface size. In othe
On Thu, 16 May 2013 16:43:52 -0500
Jason Ekstrand wrote:
> The point of this soi is to allow surfaces to render the same size on
> different density outputs.
Are you serious? Really? Same size measured in meters?
I do not think that will ever work:
http://blogs.gnome.org/danni/2011/12/15/more-o
Hi Alexander,
nice to see this going forward, and sorry for replying so rarely and
late.
On Thu, 16 May 2013 15:49:36 +0200
al...@redhat.com wrote:
> From: Alexander Larsson
>
> This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
> event. These together lets us support aut
Alexander Larsson wrote:
You can make a surface of any integer size (and it has to be integer due
to existing APIs on surface coordinates/sizes), however the *buffer* has
to be an integer multiple of the surface size. In other words, surface
sizes and positions are described in the global compos
On tor, 2013-05-16 at 10:05 -0500, Jason Ekstrand wrote:
> I still think we can solve this problem better if the clients, instead
> of providing some sort of pre-scaled buffer that matches the output's
> arbitrary scale factor, simply told the compositor which output they
> rendered for. Then ever
On tor, 2013-05-16 at 10:57 -0700, Bill Spitzak wrote:
> al...@redhat.com wrote:
>
> > Coordinates
> > in other parts of the protocol, like input events, relative window
> > positioning and output positioning are still in the compositor space
> > rather than the scaled space. However, input has su
On May 16, 2013 1:11 PM, "Bill Spitzak" wrote:
>
> Jason Ekstrand wrote:
>
>> I still think we can solve this problem better if the clients, instead
of providing some sort of pre-scaled buffer that matches the output's
arbitrary scale factor, simply told the compositor which output they
rendered f
Jason Ekstrand wrote:
I still think we can solve this problem better if the clients, instead
of providing some sort of pre-scaled buffer that matches the output's
arbitrary scale factor, simply told the compositor which output they
rendered for.
That is equivalent to providing a scale factor
al...@redhat.com wrote:
Coordinates
in other parts of the protocol, like input events, relative window
positioning and output positioning are still in the compositor space
rather than the scaled space. However, input has subpixel precision
so you can still get input at full resolution.
If I un
On May 16, 2013 8:44 AM, wrote:
>
> From: Alexander Larsson
>
> This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
> event. These together lets us support automatic upscaling of "old"
> clients on very high resolution monitors, while allowing "new" clients
> to take advantag
From: Alexander Larsson
This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
event. These together lets us support automatic upscaling of "old"
clients on very high resolution monitors, while allowing "new" clients
to take advantage of this to render at the higher resolution w
30 matches
Mail list logo
