High-DPI Support in Qt 5.6

Qt 5.6 brings improved high-DPI support, in the form of better support for the devicePixelRatio scaling mode. In this blog we’ll look at how to configure and enable it, from the perspective of a Qt application user and a Qt application developer.

Unscaled sammegame vs scaled samegame

Developing applications won’t be covered in depth now, but has to some extent been covered earlier. The short story is that applications generally benefit from this high-DPI mode even without modifications.

This high-DPI mode is a virtualization mode, where there is not necessarily a 1:1 correspondence between a unit in the QWidget/Quick item coordinate system and a pixel on screen. One “unit” then has constant visual size across systems with different display densities, and actual screen pixel density is to a large degree hidden from the application.

Dots Per Inch (DPI) is the traditional measurement for display density, where a standard density display has a DPI value of 72 or 96. Qt as always scaled fonts automatically according to the system DPI, and then the application code was responsible for scaling hardcoded layout sizes. The Qt styles would to a certain degree adapt to the font size. The devicePixelRatio mode is different in two ways: First, the display density is expressed as a scale factor — the devicePixelRatio in Qt — ranging from 1 to n. Second, the scale factor is applied lower in the stack (on the Apple platforms at the OS level), and is less directly used in application code.

There is often a fixed relation between DPI and scale factors on a given platform:

Android DPI and scale factors

class	DPI	Scale Factor
ldpi	120	0.7
mdpi	160	1
hdpi	240	1.5
xhdpi	320	2.0
xxhdpi	480	3.0
xxxhdpi	640	4.0

From stackoverflow. Quiz: Why is 1x 160 DPI on Android, compared to ~90 on desktop?

Demonstrating rendering at display densities on a blog is difficult. What we can do instead change the devicePixelRatio Qt sees while keeping the display scale factor constant. This results in larger visual sizes at higher devicePixelRatios:

The Qt Labs Controls SpinBox at various scale factors, including the unsupported 1.5x.

<strong<Enabling high-DPI support: Qt needs to be provided with a scale factor for all displays on the system. There are several possible sources for the scale factors: The values can be provided directly by the OS, Qt can compute them based on traditional display metrics provided by the operating system (such as the DPI value), or the user or developer can provide them directly. The mechanisms for setting and enabling the sources are environment variables and application attributes.

Historical Sidebar:Qt 5.4 and Qt 5.5 on X11 and Windows supports setting the devicePixelRatio with QT_DEVICE_PIXEL_RATIO=n (integer only). This setter has now been deprecated and replaced with several others, as described below.

Let’s look at three different cases:

Case I: The operating implements high-DPI scaling and provides a scale factor.

This is the situation for the Apple platforms – the OS enables the high-dpi mode, and Qt and the application come along for the ride.

This is also the case for Qt on Wayland when the Wayland display server is configured with scaling enabled:

./weston --scale 2

For the experimentally inclined, Qt for Native Client also gets a scale factor set when browser zoom is activated.

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:

QT_AUTO_SCREEN_SCALE_FACTOR=1 ./myApp

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_WIDTH, QT_QPA_EGLFS_HEIGHT and the display pixel size.

Enabling can also be vetoed, either by environment variable or by the application:

QT_AUTO_SCREEN_SCALE_FACTOR=0 ./myApp

QGuiApplication::setAttribute(Qt::AA_DisableHighDpiScaling)

The use-cases for vetoing are “I’m not getting correct DPI values from my displays” and “my application really needs to work in display pixels”. Note that this vetoing only disables “Case II” scaling: Qt can of course not change how the OS works, and manual set scale factors (below) are also kept as as a separate case.

Case III: Setting a scale factor manually.
Supported Cross-platform.

QT_SCREEN_SCALE_FACTORS=1;2;1 ./myApp

Sets the scale factors for all screens. Screen order is QApplication::screens() order. This setter assumes that text has already been properly scaled for the display, through the DPI setting, and then scales the rest of the user interface to match.

QT_SCALE_FACTOR=2 ./myApp

Sets a global scale factor for the entire application, scaling everything uniformly. This final option is useful for development and testing, and allows you to test any scale factor on any hardware. It can also be useful for some embedded scenarios – for example if you are targeting a single display type with a full-screen application: tweak the scale factor until the UI has the correct visual size.

The finer points:

Q: What happens if I use more than one of these setters?
A: The scale factors are multiplicative. Setting QT_SCALE_FACTOR=2 on a 2x device gives an effective devicePixelRatio of 4.

Q: Are non-integer scale factors supported?
A: Qt uses qreal in the API, and will allow setting non-integer scale factors via QT_SCALE_FACTOR. However, Qt does not guarantee that graphics and styles will be glitch-free in that case. Styles may break first: the fusion style is generally most scalable. The Qt platform plugins round the reported scale factors to the nearest integer.

Q: Could a scale factor of 0.5 allow me to work in device pixels on a 2x device?
A: That’s uncharted waters, but a possibility.

Availability
The new High-DPI functionality is part of Qt 5.6 release. To try it out, please check out the Qt 5.6 Beta.

The post High-DPI Support in Qt 5.6 appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1nMvI49

Qt for Native Client (and emscripten)

Qt for Native client has been in development for a while, and I’m pleased to announce that the project again has reached working status: running Qt applications (Qt Widgets and Qt Quick) sandboxed in the Chrome browser. In this post I’ll talk about the background of native code on the web and how to get started with Qt.

Qt for Native Client is available as an unsupported tech preview. Get the source code form code.qt.io:

git clone http://ift.tt/1LCdtao .
git checkout wip/nacl

The above “git clone” will give you qtbase only – If you are interested in using Qt Quick then you probably want a complete Qt checkout with the wip/nacl branch for QtBase.

See the presentation at the the Qt World Summit
Qt for Native Client will be presented at the Qt World Summit. Register today!

A brief history of Native Code on the Web

Native Client (NaCl) is a sandbox for native x86 code, first published back in 2009, and later extended to support x86_64 and ARM. Portable Native Client (PNaCl) is built on top of NaCl and defines an intermediate architecture-independent format for distribution. PNaCl binaries are translated to NaCl binaries on first load by the browser. Chrome runs PNaCl binaries from the Web, NaCl binaries from the Chrome App store or if enabled in browser settings. Other browser vendors have showed little interest in this line of technology.

Emscripten compiles native code to JavaScript which can run on all browsers. Later versions of Emscripten improves performance (on cooperating browsers) by using the ASM JS subset of JavaScript.

WebAssembly is a joint effort between some of the larger browser vendors, which target “is to promote early-stage cross-browser collaboration on a new, portable, size- and load-time-efficient format suitable for compilation to the web.” Compatibility for non-WebAssembly browsers is provided in the form of a WebAssembly loader implemented in JavaScript.

The Native Client SDK

The Native Client SDK is versioned along with Chrome and follows the same 6-week release cycle. The SDK contains an update script which fetches new versions and updates ‘canary’.

$ ls nacl_sdk/
        pepper_40
        pepper_41
        pepper_canary

‘pepper_NN/toolchain’ then contains PNaCl and NaCl toolchains. The “mac” in the names is the host, produced binaries are OS independent. The Qt tech preview currently supports the ‘pnacl’ and ‘newlib’ toolchains, using static builds.

$ ls nacl_sdk/pepper_41/toolchain
        mac_arm_newlib
        mac_pnacl
        mac_x86_glibc
        mac_x86_newlib

Finally we find the compiler binaries and conclude we are dealing with a cross-compiler:

$ ./nacl_sdk/pepper_41/toolchain/mac_pnacl/bin/i686-nacl-clang++ hello.cpp -o hello.nexe
$ file hello.nexe
hello.nexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$ ./hello
-bash: ./hello.nexe: cannot execute binary file

Emscripten

Emscripten is typically distributed by your platforms package manager. On OS X:

        brew install emscripten

This gives you the ‘em++’ compiler and friends – there are no versions or toolchain variants. em++ can produce “executable” .js files:

$em++ hello.cpp -o hello.js
node hello.js
“Hello World”

API and Platform

Programs that want to do something more interesting than printing to standard out need an API to interface against. In Qt, this is the domain of the QPA platform plugin. Native Client provides PPAPI (’Pepper’) which provides a C and C++ API for the features covered by the HTML (5) specification. For example, Pepper gives access to mouse and keyboard events, and provides 2D or 3D graphics contexts.

Emscripten also has a similar API. Qt could have used it but instead uses pepper.js, which is a re-implementation of the Pepper API on top of Html, which allows us to re-use the exiting pepper platform plugin. (It could be said that adding this level of indirection is in the spirit of compiling C++ to JavaScript). Emscripten support is still very expermental: QtCore and QtGui runs with raster graphics, the OpenGL, QtWidgets and QtQuick modules are largely untested.

Setting up Qt

The workflow is similar to using Qt for any other platform:
1. Configure and build Qt.
2. Build the application.
3. Deploy. (nacldeployqt)

The following is a simplified overview, complete getting started instructions are available at qtbase/README.md.

1. Use the provided configure script, select a NaCl toolchain or emscripten (We treat emscripten as a nacl variant.)

./nacl-configure mac_pnacl release

Build Qt:

make qtmodule-qtbase (or qtmodule-qtdeclarative)

2. Build the application

/path/to/qmake && make

3. Run nacldeployqt

/path/to/nacldeployqt application.nexe

This creates supporting files for the application: a html file, the qtloader.js script, manifest files.

In addition, nacldeployqt provides some convenience:

   -—run: Start Chrome, run the application
   -—debug: Start Chrome and nacl-gdb, run the applicatjon with attached debugger

Finally it runs:

Questions? Interested in contributing to the development of Qt for Native Client? Contact us here or on #qt-labs on irc (freenode).

The post Qt for Native Client (and emscripten) appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1LCdsTR

Qt Weekly #24: High-dpi QtWayland

Those of you following QtWayland development closely might have seen commit 7ef5e2e4 – Implement high-dpi support. In this blog we’ll look at some examples and show how to test the support on high and normal dpi hardware.

Wayland

Wayland 1.2 added support for high-dpi scaling via

• wl_output::scale


• wl_surface::set_buffer_scale

wl_output::scale is used by the compositor to inform the client that it will scale buffers by the given scale factor (presumably because it is compositing to a high resolution display). The client then has the option of providing high resolution buffers and bypass the compositor scaling. This is done by calling set_buffer_scale (and then actually creating larger buffers). Typical values for the scale factor is 1 and 2; Wayland supports integer factors only. From he client point of view the buffer sizes are the only thing that changes with the scale factor, other wl_surface geometry is not multiplied by it.

Qt

Creating larger buffers and rendering high-dpi content is handled internally by Qt using the existing devicePixelRatio implementation. This implementation is also in use on OS X and iOS, and – via the QT_DEVICE_PIXEL_RATIO environment variable in Qt 5.4 – in experimental form on X11 and Windows. The details of this mode have been covered elsewhere; the main thing to be aware of as an app developer is that you need to provide high-resolution raster artwork, and that raw OpenGL are in device pixels and see the full display resolution.

Weston

Recent versions of the Weston compositor (I’m using 1.6.0) supports running in scaled mode:

./bin/weston --width=640 --height=480 --scale=2

We can then launch any Qt app, as usual:

./anyqtapp -platform wayland

high-dpi and normal-dpi rendered Flat style demo – best viewed at full size

The screenshots illustrate the benefits of the devicePixelRatio scaling mode: The application is automatically rendered at a higher resolution; no modifications to app code is needed. In cases where high-resolution content is not available there is a graceful degradation to low-resolution content, without breaking layouts or by displaying “small” user interface elements.

High-dpi support is currently implemented in the “dev” branch of QtWayland and are on track to be released with Qt 5.5.

Source :- Qt Blog http://ift.tt/1H5jg7f