On Tue, May 14, 2013 at 9:46 PM, Bill Spitzak spit...@gmail.com 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
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
On Mon, May 13, 2013 at 8:52 PM, Jason Ekstrand ja...@jlekstrand.netwrote:
On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson al...@redhat.comwrote:
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
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
desired
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 two
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.
On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson al...@redhat.comwrote:
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
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
al...@redhat.com
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
On Tue, May 14, 2013 at 3:19 PM, Alexander Larsson al...@redhat.com 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
al...@redhat.com
I don't think it should really be allowed to not apply the
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 (and
On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson al...@redhat.com 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,
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.
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
On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak spit...@gmail.com 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
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
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
On Mon, 13 May 2013 11:16:07 +0200
Alexander Larsson al...@redhat.com 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:
On Mon, May 13, 2013 at 11:56 AM, Alexander Larsson al...@redhat.comwrote:
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
On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote:
On Mon, 13 May 2013 11:16:07 +0200
Alexander Larsson al...@redhat.com 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.
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
On Mon, 13 May 2013 13:14:29 +0200
Alexander Larsson al...@redhat.com 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 al...@redhat.com wrote:
On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
Also, we
Mon, May 13, 2013 at 1:26 PM, Alexander Larsson al...@redhat.com 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
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 pick a
On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson al...@redhat.com 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
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 fractional
On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson al...@redhat.com 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.
From: Alexander Larsson al...@redhat.com
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
On Wed, May 8, 2013 at 6:51 AM, al...@redhat.com 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
On ons, 2013-05-08 at 10:43 -0400, Todd Showalter wrote:
On Wed, May 8, 2013 at 6:51 AM, al...@redhat.com 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
On Wed, May 8, 2013 at 11:07 AM, Alexander Larsson al...@redhat.com 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
Hi Alex Todd,
On Wed, May 8, 2013 at 11:06 AM, Todd Showalter t...@electronjump.comwrote:
On Wed, May 8, 2013 at 11:07 AM, Alexander Larsson al...@redhat.com
wrote:
We're moving to a HiDPI world. With 3DTV failing in the market,
it's looking like the TV manufacturers are going to
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. I
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
On Wed, May 8, 2013 at 3:51 PM, Jason Ekstrand ja...@jlekstrand.net 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
On Wed, May 8, 2013 at 5:19 PM, Todd Showalter t...@electronjump.com wrote:
On Wed, May 8, 2013 at 3:51 PM, Jason Ekstrand ja...@jlekstrand.net 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
35 matches
Mail list logo
