[Development] OpenGL drivers

Thu Dec 5 10:34:58 CET 2013

On Dec 4, 2013, at 12:34 PM, Thomas Hartmann <Thomas.Hartmann at digia.com> wrote:

> Hi,
> 
> what is already possible is to read the font.pixelSize property for a 
> specific point size or just using the implicit size of a text item.
> One main problems with layouts following physical units (pt, cm), is 
> that icons (all pixel based resources) have to be scaled accordingly (or 
> have a "random" size). And most icons are still pixel and not vector 
> based and scale badly.
> 
> Eventually on high dpi screens it would make sense of course, to ditch 
> all pixels and only use vector bases resources. But this is not our 
> reality, yet.

Even with vector based resources you’ll probably like to use different ones depending on how much device pixels you have for rendering a specific icon. A 32x32 pixel icon can contain much more details than a 16x16 pixel icon, instead of just being a "nicely rendered" 16x16 icon. Or do vector based formats actually have support for that?

Br, Eike

> Kind Regards,
> Thomas Hartmann
> 
> Am 04/12/2013 11:47, schrieb Sletta Gunnar:
>> 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
>> 
>> ________________________________________
>> 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
>> 
> 
> 
> -- 
> Thomas Hartmann
> Software Engineer
> Nokia, Qt Development Frameworks
> 
> Digia Germany GmbH
> 
> Rudower Chausse 13, 12489 D-Berlin
> 
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht 
> Charlottenburg, HRB 144331 B,
> Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
> 
> Email: thomas.hartmann at digia.com
> 
> 
> Digia Germany is a group company of Digia Plc,
> 
> Valimotie 21, FI-00380 Helsinki Finland
> 
> Visit us at: www.digia.com
> 
> ------------------------------------------------------------------
> 
> PRIVACY AND CONFIDENTIALITY NOTICE
> 
> This message and any attachments are intended only for use by the named 
> addressee and may contain privileged and/or confidential information. If 
> you are not the named addressee you should not disseminate, copy or take 
> any action in reliance on it. If you have received this message in 
> error, please contact the sender immediately and delete the message and 
> any attachments accompanying it. Digia Germany GmbH and Digia Plc do not 
> accept liability for any corruption, interception, amendment, tampering 
> or viruses occurring to this message.
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt

Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B