[Development] OpenGL drivers

[Mark Gaiser]

On Wed, Dec 4, 2013 at 12:37 PM, Mitch Curtis <mitch.curtis at digia.com> wrote:
> On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
>> QWidget has the exact opposite problem. Layouts, styles and rendering happens in pixel units while fonts are sized in point size. This is also a problem when moving between platfoms as the pixelsize of a point has a different definition on each platform. When running widgets on a hidpi screen, the fonts are usually huge compared to spacing, lines and icons. In addition to looking quite ugly it easily breaks the layout scheme set up by the application because the text takes up too much space.
>>
>> As long as one sticks to one unit type through the application everything is fine. Mixing leads to problems.
>>
>> Just thinking out loud:
>>
>> Sticking to pixels makes it possible for the application developer to make the right decision based on what he/she wants to achieve. Layout out relative to millimeters can quite easily be done by providing supporting logic in Qt.
>>
>> If we added conversion functions for inch(), cm(), mm(), points() to QQuickItem, it could look up its current window/screen object and figure out the relationship between each unit for the screen the item is on and just set that. The app can then layout in the unit space it prefers with information readily available.
>>
>> Text {
>>      font.pixelSize: cm(0.5);
>>      anchors.left: parent.left
>>      anchors.margins: cm(0.25);
>> }
>>
>>
>> Making them functions makes it impossible to listen for screen changes which in turn trigger dpi changes so they would have to be properties...
>>
>> Text {
>>      font.pixelSize: 0.5 * cm;
>>      anchors.left: parent.left
>>      anchors.margins: 0.25 * cm;
>> }
>>
>> The properties would look up the item's window and then the screen and do the calculation from there so no extra memory for each item to store the properties. And since they don't change all that often, the added calculation is a negligible overhead. When the item is not associated with a window, it will have to use the OS definition of a point instead, usually 72 or 96.
>>
>> Just an idea.
>>
>> -
>> Gunnar
>>
>
> That's a pretty cool idea! It would make it so painless to design stuff
> for different screens' DPIs.

I'm confused.
I thought we has pointSize for that reason, no?

To me it sounds like two different ways to accomplish the same thing.
Also, if i'm setting a font.pixelSize i'm expexting pixels to be
drawn. adding a "* cm" makes that moot since the real pixels that will
be drawn are calculated based on whatever cm is.

In other words, don't use pixelSize for it. Just making up a name now,
but how about something like this:

Text {
  ...
  font.realSize: 0.5 cm
  ...
}

seems more readable to me and gives me the expectation that the font
is going to be 0.5 CM (per char).

>
>> ________________________________________
>> Fra: development-bounces+gunnar.sletta=digia.com at qt-project.org [development-bounces+gunnar.sletta=digia.com at qt-project.org] på vegne av Thiago Macieira [thiago.macieira at intel.com]
>> Sendt: 3. desember 2013 18:09
>> To: development at qt-project.org
>> Emne: Re: [Development] OpenGL drivers
>>
>> On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
>>> Hi,
>>>
>>> we really should think about introducing em or percent for font sizes.
>>>
>>> But non pixel size fonts create a lot of problems for complex layouts.
>>
>> QWidget has worked with that for 15 years, so I don't accept that as an
>> excuse. We have anchor layouts in Qt Quick, which are a lot more powerful than
>> the grids and spacers that we used in QWidget.
>>
>> Desktop support does not require pixel perfection. It does require scaling
>> over widely different resolutions and DPIs, though -- from 1366x768 to
>> 3200x1800, for example.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>    Software Architect - Intel Open Source Technology Center
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development