Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-26 Thread Jason H 
> > The approaches available currently either
> > 
> > 1) scale everything after rendering (eg with SetProcessDPIAware())
> > 2) scale coordinates to screen metrics before rendering 
> > (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
> > 
> > The first approach gives a blurry result because of up/down scaling and is 
> > not satisfying.
> > 
> > The second approach scales all coordinates, making it impossible to specify 
> > 'a one/two pixel border' without 
> > that getting scaled too. Additionally, the AA_EnableHighDpiScaling will 
> > only apply integer scaling, so on a 
> > screen with 150% scaling, the widget is scaled to 200%.  
> 
> I had a request to explain the problem with screenshots, so I created 
> 
>  https://bugreports.qt.io/browse/QTBUG-63402
> 
> with screenshots showing the previously posted code with the available 
> approaches and APIs to solving
> the problem, along with a screenshot showing the result of this proposal.

My crazy thought of the day:
The HTML 5 Canvas blits text 0.5 pixels offset. How would that change the top 
150% render?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-25 Thread Stephen Kelly via Development 
> The approaches available currently either
> 
> 1) scale everything after rendering (eg with SetProcessDPIAware())
> 2) scale coordinates to screen metrics before rendering 
> (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
> 
> The first approach gives a blurry result because of up/down scaling and is 
> not satisfying.
> 
> The second approach scales all coordinates, making it impossible to specify 
> 'a one/two pixel border' without 
> that getting scaled too. Additionally, the AA_EnableHighDpiScaling will only 
> apply integer scaling, so on a 
> screen with 150% scaling, the widget is scaled to 200%.  

I had a request to explain the problem with screenshots, so I created 

 https://bugreports.qt.io/browse/QTBUG-63402

with screenshots showing the previously posted code with the available 
approaches and APIs to solving
the problem, along with a screenshot showing the result of this proposal.

Thanks,

Stephen.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-22 Thread Stephen Kelly via Development 
> It's not like devices change DPI, though if
> you have multiple monitors this assumption may be invalid if the user moves
> the window to between screens or another screen.

This is indeed the topic of this thread. The other issues you raise look like 
they should be raised on another thread.

Thanks,

Stephen.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-22 Thread Jason H 
First let me say that I have no idea what I'm talking about.

That said, given all the times I've used Qt and experienced issues,
I only remember had problems when dealing with fonts, and the Canvas element on 
IOS. (I think the Canvas still is blurry)
I've used headless Qt for printing charts (remember Qt Charts?) and all the 
words came out elided. (Qt 5.2 on Amazon AMI). Rendering at 72 DPI worked but 
300 DPI was the problem. IN the end I was never happy, I kept the strings short 
to avoid eliding and scaled the text up while also increasing the DPI. 
Similarly, iOS seemed to have the most font issues. I liked the idea of using 
point size for text, but it wouldn't ever behave how it should (there were some 
other issues with not being able to find what size text was, I think this has 
been fixed)

Given all my problems, I found myself wondering why points vs pixels was so 
hard? The I figured everything specified in points should be converted to 
display pixels via device metrics? It's not like devices change DPI, though if 
you have multiple monitors this assumption may be invalid if the user moves the 
window to between screens or another screen. 



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-22 Thread Stephen Kelly via Development 


> From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of 
> Jean-Michaël Celerier
> Sent: Friday 22 September 2017 13:25
> To: Stephen Kelly 
> Cc: Jean-Michaël Celerier ; 
> development@qt-project.org
> Subject: Re: [Development] New approach to hi-dpi and coordinate system for 
> layouts in Qt 6
> 
> Indeed, this seemed too easy :p 

Right ;p.

> Sligthly related, but the second approach with the coordinates makes me 
> remember
> this bug report (about QML, but the problem space is similar and proposed 
> solutions involved adding units to values): 
> https://bugreports.qt.io/browse/QTBUG-11655

This is a request for physical units.  I mentioned physical units in my 
previous 
mail, but I don't know how important they are for this design, which is not so 
much 
concerned about units, as such, but about multiple screens with different DPIs 
etc.

> > A disadvantage of the QCoordinate approach is that the values are not 
> > comparable
> > to each other without a screen. 
> 
> There is also the problem of a single Qt window between multiple screens with 
> different DPI so it'd be at least one screen per coordinate

I think that's out of scope.  Windows API doesn't even allow accounting for 
that.  Maybe you can go low-level and find some work around, but it's not 
really 
something applications (even outside of Qt) do.

> (maybe even worse if 
> someone wants to use a QCoordinate for computing a distance that would span 
> multiple screens ?)
> 
> > One of the issues raised so far is that this QCoordinate stores only
> > pixels and points, 
> 
> shouldn't this be implemented as a variant instead ? (I mean, Qt6 *will* 
> require C++17, right ? :p) 

Nope. The point is that *both* pixels and points must be stored.  std::variant 
is a sum type.  That's not what's needed here.

Thanks,

Stephen.
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-22 Thread Stephen Kelly via Development 

Hi Jean-Michaël,

The issue is layouting, not painting. Sorry for not making that clear.

Feel free to modify the example code I posted if you think you have a general 
solution with QPen::setCosmetic alone to fix the layout issues.

Thanks,

Stephen.

From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of 
Jean-Michaël Celerier
Sent: Thursday 21 September 2017 11:29
To: Stephen Kelly 
Cc: development@qt-project.org
Subject: Re: [Development] New approach to hi-dpi and coordinate system for 
layouts in Qt 6

> making it impossible to specify 'a one/two pixel border'
Correct me if I am wrong, but isn't this what QPen::setCosmetic is used for ?
Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Sep 21, 2017 at 11:37 AM, Stephen Kelly via Development 
> wrote:

Hi,

Qt 5 has several approaches to attempting to size/scale a UI when moving 
between screens which have
different APIs.  There is a summary here:

https://vicrucann.github.io/tutorials/osg-qt-high-dpi/

The approaches available currently either

1) scale everything after rendering (eg with SetProcessDPIAware())
2) scale coordinates to screen metrics before rendering 
(QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))

The first approach gives a blurry result because of up/down scaling and is not 
satisfying.

The second approach scales all coordinates, making it impossible to specify 'a 
one/two pixel border' without that getting scaled too. Additionally, the 
AA_EnableHighDpiScaling will only apply integer scaling, so on a screen with 
150% scaling, the widget is scaled to 200%.

Adding a floating-point based API would not be a solution because it would 
result in painting artefacts.  This is an important point.  An approach like 
that won't satisfy designers.  The approach in

https://codereview.qt-project.org/#/c/157174/

resolves a scaling issue but does not address painting artefacts.

So, we need to find flexible and imaginative solutions.

I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP 
doesn't (yet?) go as far as approaches to addressing the problem, so I am 
writing here to see if there is wider interest in the topic.  One of the points 
he made is that some users are happy with the current state of Qt APIs and 
behavior, or would be happy with downsampling after rendering (blurry).

I don't know how widespread that acceptance would be, but I've worked on 
several teams where it would not be acceptable.

The underlying problem is that the Qt APIs do not provide a way to specify the 
units to use in layouts AND to combine values with those units.  We need to be 
able to specify coordinates which will be scaled to an appropriate number of 
pixels on the screen, but also to be able to specify coordinates in exact 
pixels (common for things like having a 'one/two pixel border' etc).  Then, Qt 
should compute the actual number of pixels to paint based on the current screen.

The approach we discussed (this is only the ideas-stage, remember!) with Morten 
is to change APIs which specify layouts to use a new unit-sensitive coordinate 
type instead of int.  This new QCoordinate type stores values in both points 
and pixels and has a toPixels method which computes the required pixel value 
for the screen.

https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d

QCoordinates can be created with C++11 user-defined literal niftyness:

  auto coord = 34_pt + 4_px;

This also implies a requirement to have QSize/QPoint etc equivalents based on 
QCoordinate.  We haven't put much thought into this code duplicatation etc, 
focusing only on whether we can solve the problems with this approach (or 
another approach?)

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-21 Thread Jean-Michaël Celerier 
> making it impossible to specify 'a one/two pixel border'

Correct me if I am wrong, but isn't this what QPen::setCosmetic is used for
?

Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Sep 21, 2017 at 11:37 AM, Stephen Kelly via Development <
development@qt-project.org> wrote:

>
>
> Hi,
>
>
>
> Qt 5 has several approaches to attempting to size/scale a UI when moving
> between screens which have
>
> different APIs.  There is a summary here:
>
>
>
> https://vicrucann.github.io/tutorials/osg-qt-high-dpi/
>
>
>
> The approaches available currently either
>
>
>
> 1) scale everything after rendering (eg with SetProcessDPIAware())
>
> 2) scale coordinates to screen metrics before rendering
> (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
>
>
>
> The first approach gives a blurry result because of up/down scaling and is
> not satisfying.
>
>
>
> The second approach scales all coordinates, making it impossible to
> specify 'a one/two pixel border' without that getting scaled too.
> Additionally, the AA_EnableHighDpiScaling will only apply integer scaling,
> so on a screen with 150% scaling, the widget is scaled to 200%.
>
>
>
> Adding a floating-point based API would not be a solution because it would
> result in painting artefacts.  This is an important point.  An approach
> like that won't satisfy designers.  The approach in
>
>
>
> https://codereview.qt-project.org/#/c/157174/
>
>
>
> resolves a scaling issue but does not address painting artefacts.
>
>
>
> So, we need to find flexible and imaginative solutions.
>
>
>
> I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP
> doesn't (yet?) go as far as approaches to addressing the problem, so I am
> writing here to see if there is wider interest in the topic.  One of the
> points he made is that some users are happy with the current state of Qt
> APIs and behavior, or would be happy with downsampling after rendering
> (blurry).
>
>
>
> I don't know how widespread that acceptance would be, but I've worked on
> several teams where it would not be acceptable.
>
>
>
> The underlying problem is that the Qt APIs do not provide a way to specify
> the units to use in layouts AND to combine values with those units.  We
> need to be able to specify coordinates which will be scaled to an
> appropriate number of pixels on the screen, but also to be able to specify
> coordinates in exact pixels (common for things like having a 'one/two pixel
> border' etc).  Then, Qt should compute the actual number of pixels to paint
> based on the current screen.
>
>
>
> The approach we discussed (this is only the ideas-stage, remember!) with
> Morten is to change APIs which specify layouts to use a new unit-sensitive
> coordinate type instead of int.  This new QCoordinate type stores values in
> both points and pixels and has a toPixels method which computes the
> required pixel value for the screen.
>
>
>
> https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d
>
>
>
> QCoordinates can be created with C++11 user-defined literal niftyness:
>
>
>
>   auto coord = 34_pt + 4_px;
>
>
>
> This also implies a requirement to have QSize/QPoint etc equivalents based
> on QCoordinate.  We haven't put much thought into this code duplicatation
> etc, focusing only on whether we can solve the problems with this approach
> (or another approach?) at all.
>
>
>
> A disadvantage of the QCoordinate approach is that the values are not
> comparable to each other without a screen.  So operator<() can't be
> implemented for example, but a separate purposeful API would be needed for
> things like that.
>
>
>
> One of the issues raised so far is that this QCoordinate stores only
> pixels and points, but not other units which may be wanted, such as
> physical units like centimeters.  Morten noted that there are not many
> known use-cases for such units and that they mean little if a projector is
> in use.
>
>
>
> This is of course a Qt 6 change, and now is approximately the time to
> discuss Qt 6 changes.  I don't know if anyone will be in Berlin who wants
> to discuss this at QtCS.  Shout if you want to discuss this there and I'll
> see if I can go over for it.
>
>
>
> Thanks,
>
>
>
> Stephen.
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

2017-09-21 Thread Stephen Kelly via Development 

Hi,

Qt 5 has several approaches to attempting to size/scale a UI when moving 
between screens which have
different APIs.  There is a summary here:

https://vicrucann.github.io/tutorials/osg-qt-high-dpi/

The approaches available currently either

1) scale everything after rendering (eg with SetProcessDPIAware())
2) scale coordinates to screen metrics before rendering 
(QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))

The first approach gives a blurry result because of up/down scaling and is not 
satisfying.

The second approach scales all coordinates, making it impossible to specify 'a 
one/two pixel border' without that getting scaled too. Additionally, the 
AA_EnableHighDpiScaling will only apply integer scaling, so on a screen with 
150% scaling, the widget is scaled to 200%.

Adding a floating-point based API would not be a solution because it would 
result in painting artefacts.  This is an important point.  An approach like 
that won't satisfy designers.  The approach in

https://codereview.qt-project.org/#/c/157174/

resolves a scaling issue but does not address painting artefacts.

So, we need to find flexible and imaginative solutions.

I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP 
doesn't (yet?) go as far as approaches to addressing the problem, so I am 
writing here to see if there is wider interest in the topic.  One of the points 
he made is that some users are happy with the current state of Qt APIs and 
behavior, or would be happy with downsampling after rendering (blurry).

I don't know how widespread that acceptance would be, but I've worked on 
several teams where it would not be acceptable.

The underlying problem is that the Qt APIs do not provide a way to specify the 
units to use in layouts AND to combine values with those units.  We need to be 
able to specify coordinates which will be scaled to an appropriate number of 
pixels on the screen, but also to be able to specify coordinates in exact 
pixels (common for things like having a 'one/two pixel border' etc).  Then, Qt 
should compute the actual number of pixels to paint based on the current screen.

The approach we discussed (this is only the ideas-stage, remember!) with Morten 
is to change APIs which specify layouts to use a new unit-sensitive coordinate 
type instead of int.  This new QCoordinate type stores values in both points 
and pixels and has a toPixels method which computes the required pixel value 
for the screen.

https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d

QCoordinates can be created with C++11 user-defined literal niftyness:

  auto coord = 34_pt + 4_px;

This also implies a requirement to have QSize/QPoint etc equivalents based on 
QCoordinate.  We haven't put much thought into this code duplicatation etc, 
focusing only on whether we can solve the problems with this approach (or 
another approach?) at all.

A disadvantage of the QCoordinate approach is that the values are not 
comparable to each other without a screen.  So operator<() can't be implemented 
for example, but a separate purposeful API would be needed for things like that.

One of the issues raised so far is that this QCoordinate stores only pixels and 
points, but not other units which may be wanted, such as physical units like 
centimeters.  Morten noted that there are not many known use-cases for such 
units and that they mean little if a projector is in use.

This is of course a Qt 6 change, and now is approximately the time to discuss 
Qt 6 changes.  I don't know if anyone will be in Berlin who wants to discuss 
this at QtCS.  Shout if you want to discuss this there and I'll see if I can go 
over for it.

Thanks,

Stephen.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development