Re: [PATCH 0/2] Support for high DPI outputs via scaling

John Kåre Alsaker wrote: For example a compositor may want to use a 1-1.2 range with 1.1 as the desired scaling factor. A clients which are only able to draw at integer scaling factor would round that up to 2 and let the composito

Re: [PATCH 0/2] Support for high DPI outputs via scaling

John Kåre Alsaker wrote: On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak > wrote: John Kåre Alsaker wrote: The size of a window should always be in pixels at the protocol level. Note that this is in direct contradiction to the proposed scaler

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Tue, May 14, 2013 at 9:46 PM, Bill Spitzak wrote: > > > John Kåre Alsaker wrote: > >> >> I expect a compositor to render deviations of the desired scaling >> factor without scaling windows. The range when this is allowed is >> reported to clients so they can try to render at a size

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak wrote: > John Kåre Alsaker wrote: > > The size of a window should always be in pixels at the protocol level. >> > > Note that this is in direct contradiction to the proposed scaler api. In > it the size of the window is in transformed pixels. > > I t

Re: [PATCH 0/2] Support for high DPI outputs via scaling

Alexander Larsson wrote: In this case our proposals differs. The compositor knows it's not resizing the window so it simply passes 2000x2000 along to the configure arguments. How can the compositor know its not resizing the window? Only the app knows if it can render at a different scaling fac

Re: [PATCH 0/2] Support for high DPI outputs via scaling

John Kåre Alsaker wrote: I might have been unclear. Users may want to disable resizing of buffer pixels in the compositor. However clients which able to draw at the correct scaling factor should still do so and appear pixel perfect. Clients that don't want scaling can simply "lie" and claim t

Re: [PATCH 0/2] Support for high DPI outputs via scaling

Alexander Larsson wrote: Now, a non-naive client will get the same maximize reply of 1000x1000, but in this case we want it to create a buffer of 2000x2000 (with scale 2) since it knows the window is on a high-dpi monitor. So, there is a natural separation of the surface size (1000x1000) and the

Re: [PATCH 0/2] Support for high DPI outputs via scaling

John Kåre Alsaker wrote: I expect a compositor to render deviations of the desired scaling factor without scaling windows. The range when this is allowed is reported to clients so they can try to render at a size which will avoid scaling. For example a compositor may want

Re: [PATCH 0/2] Support for high DPI outputs via scaling

John Kåre Alsaker wrote: The size of a window should always be in pixels at the protocol level. Note that this is in direct contradiction to the proposed scaler api. In it the size of the window is in transformed pixels. I think now the scaler proposal should be changed. ___

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson wrote: > On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote: > > > > Obviously they are defined as such right now, since there is > > no scaling. > > But, the patch I proposed changes this, > > > > because

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote: > Obviously they are defined as such right now, since there is > no scaling. > But, the patch I proposed changes this, > > because otherwise we can't > cleanly handle backwards compatibility (an

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Tue, May 14, 2013 at 3:19 PM, Alexander Larsson wrote: > On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote: > > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson > > > > > > I don't think it should really be allowed to not apply the > > scaling. > > Users may want t

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote: > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson > > > I don't think it should really be allowed to not apply the > scaling. > Users may want to disable scaling as it's not very good looking. I > don't think

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson wrote: > On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote: > > > > > While this isn't a huge problem on GL-based compositors it > > will cause a problem for software compositors. Any scaling > > for that matter

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On tis, 2013-05-14 at 07:22 +0200, John Kåre Alsaker wrote: > We may also allow scaling factors below 1. When 0 clients should draw > using the smallest amount of pixels possible while still being > understandable. I doubt that will be very useful and clients could > just have 1 as a lower bound.

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote: > > While this isn't a huge problem on GL-based compositors it > will cause a problem for software compositors. Any scaling > for that matter is a potential problem there. However, a > factor of

Re: [PATCH 0/2] Support for high DPI outputs via scaling

> I expect a compositor to render deviations of the desired scaling factor > without scaling windows. The range when this is allowed is reported to > clients so they can try to render at a size which will avoid scaling. > > For example a compositor may want to use a 1-1.2 range with 1.1 as the > de

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, May 13, 2013 at 8:52 PM, Jason Ekstrand wrote: > On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson wrote: > >> >> On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: >> >> > >> > I don't think this will work in practice. I know for sure that >> > e.g. Gtk >> >

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson wrote: > > On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: > > > > > I don't think this will work in practice. I know for sure that > > e.g. Gtk > > is not set up to do any reasonable non-integer scaling. It >

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: > > I don't think this will work in practice. I know for sure that > e.g. Gtk > is not set up to do any reasonable non-integer scaling. It > will just > scale up all drawing by a fractiona

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson wrote: > On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote: > > > > Clients can easily scale larger features like icons, padding > > and fonts > > > and round them to pixel sizes and draw sharp output even > >

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote: > > Clients can easily scale larger features like icons, padding > and fonts > > and round them to pixel sizes and draw sharp output even > with a > > fractional scaling factor. This allows users to

Re: [PATCH 0/2] Support for high DPI outputs via scaling

Mon, May 13, 2013 at 1:26 PM, Alexander Larsson wrote: > On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote: > > > The scaling factor should not have any affect of any coordinate system > > or anything else in the protocol. It should only affect the size in > > pixels of the surfaces of t

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, 13 May 2013 13:14:29 +0200 Alexander Larsson wrote: > On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote: > > On Mon, 13 May 2013 11:16:07 +0200 > > Alexander Larsson wrote: > > > > > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > > > > > > > Also, we need to figure ou

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote: > The scaling factor should not have any affect of any coordinate system > or anything else in the protocol. It should only affect the size in > pixels of the surfaces of the clients. Clients should do any > transformations of coordinates

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote: > On Mon, 13 May 2013 11:16:07 +0200 > Alexander Larsson wrote: > > > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > > > > > Also, we need to figure out how this interacts with the proposed > > > scaling extension. Information

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, May 13, 2013 at 11:56 AM, Alexander Larsson wrote: > On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: > > I think we should allow fractional scale factors. Clients which only > > support integer scale factors should round the scale factor they get > > to a whole number. > > I do

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Mon, 13 May 2013 11:16:07 +0200 Alexander Larsson wrote: > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > > > Also, we need to figure out how this interacts with the proposed > > scaling extension. Information can be found here: > > http://lists.freedesktop.org/archives/wayland-d

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: > I think we should allow fractional scale factors. Clients which only > support integer scale factors should round the scale factor they get > to a whole number. I don't see how this is useful? The scaling has two main benefits: 1) It d

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > Is there a way to bypass the scaling? When I'm using the > mouse in > a game, I want to know the pixel position of the pointer, with > no > scaling applied. I'm going to be drawing the gui at

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Wed, May 8, 2013 at 6:14 PM, Alex Deucher wrote: > Perhaps, but what's to say the 4k uptake will be any better than 3DTV? 4K doesn't have a lot of the intrinsic problems that 3DTV has. It's just higher-res TV. 3DTV brought a ton of baggage to the party; you had to have glasses for everyo

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Wed, May 8, 2013 at 5:19 PM, Todd Showalter wrote: > On Wed, May 8, 2013 at 3:51 PM, Jason Ekstrand wrote: > >> Also, I agree that you're going to have mixed setups. Like you said, people >> replace their laptops fairly frequently. However, I have a monitor sitting >> on my desk that I bough

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Wed, May 8, 2013 at 3:51 PM, Jason Ekstrand wrote: > Also, I agree that you're going to have mixed setups. Like you said, people > replace their laptops fairly frequently. However, I have a monitor sitting > on my desk that I bought in 2004 and it's still working perfectly with no > dead pix

Re: [PATCH 0/2] Support for high DPI outputs via scaling

I think we should allow fractional scale factors. Clients which only support integer scale factors should round the scale factor they get to a whole number. We should implement this by adding a scale_factor event on wl_output (which clients can get at any time). When clients have rendered their co

Re: [PATCH 0/2] Support for high DPI outputs via scaling

Todd Showalter wrote: I'm dubious about handling things this way... If I understand his proposal, it is almost identical to the "scaler" proposal. Right now if a hi-def output has a scale of 2, the client aware of this draws the buffer twice as large and sends a scale of 2 to his api.

Re: [PATCH 0/2] Support for high DPI outputs via scaling

Hi Alex & Todd, On Wed, May 8, 2013 at 11:06 AM, Todd Showalter wrote: > On Wed, May 8, 2013 at 11:07 AM, Alexander Larsson > wrote: > > >> We're moving to a "HiDPI" world. With 3DTV failing in the market, > >> it's looking like the TV manufacturers are going to push hard on 4K, > >> and on

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Wed, May 8, 2013 at 11:07 AM, Alexander Larsson wrote: >> We're moving to a "HiDPI" world. With 3DTV failing in the market, >> it's looking like the TV manufacturers are going to push hard on 4K, >> and once 4K panels are widely available they'll work their way down to >> PCs fairly quick

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On ons, 2013-05-08 at 10:43 -0400, Todd Showalter wrote: > On Wed, May 8, 2013 at 6:51 AM, wrote: > > There are problems with this. > > We're moving to a "HiDPI" world. With 3DTV failing in the market, > it's looking like the TV manufacturers are going to push hard on 4K, > and once 4K

Re: [PATCH 0/2] Support for high DPI outputs via scaling

On Wed, May 8, 2013 at 6:51 AM, wrote: > I'm working on trying to make high DPI (i.e. retina-class) outputs > work well on Linux. I've written a proposal here: > > https://docs.google.com/document/d/1rvtiZb_Sm9C9718IoYQgnpzkirdl-wJZBBu_qLgaYyY/edit?usp=sharing I'm dubious about handling thi

[PATCH 0/2] Support for high DPI outputs via scaling

From: Alexander Larsson I'm working on trying to make high DPI (i.e. retina-class) outputs work well on Linux. I've written a proposal here: https://docs.google.com/document/d/1rvtiZb_Sm9C9718IoYQgnpzkirdl-wJZBBu_qLgaYyY/edit?usp=sharing This adds the initial protocol support needed for this. I