> > I suppose another consideration would be setting the scale based on the > > monitor you're on. I don't know how developed Android's multi monitor > > support is, but if you wanted your application to change scale when it > > moved across different density displays, I imagine the platform plugin > > would need to do some work. > Exactly, I think we want to add API to make it possible to control the QtGui > scaling per-window, in addition to QT_HIGHDPI_SCALE_FACTOR. This would be > needed for the KDE use case as well. As it stands today the platform plugin > can implement QPlatformWindow::devicePixelRatio(), but then Qt assumes the > plugin or the OS handles the scaling.
Yes, setting QtGui scaling per-window sounds like it will be necessary to support platforms where applications can span multiple monitors with different scale factors. > All in all I see three use cases: > - the platform plugin reports a scale factor when the OS scales. > - the developer sets QT_HIGHDPI_SCALE_FACTOR asking QtGui to scale (great for > testing) > - the platform plugin/desktop environment sets a scale factor and asks QtGui > to scale. It sounds like Android could indeed fall into use case #3. If you need to use QT_HIGHDPI_SCALE_FACTOR to test on your Android device, I suppose you'll need to remember the device's native scale factor and multiply by that. > Screen changes on OS X works as follows: There is a screen change event. The > platform plugin then sends an expose/repaint to Qt. The code handling the > repaint will at some point call QWindow::devicePixelRatio(), which will then > report the correct value for the new screen. > I’m not completely against adding scaling code to Android, but I would rather > see the maintenance effort go to the cross-platofrm code. If it turns you we > _do_ need the scaling code in the Android plugin for some reason, then yes > let’s do that. I'm definitely in favor of the platform independent solution now that I understand it a little better. In that case, the Android plugin would only need to set the scale factor () and cover a few corner cases like in your XCB changes: https://codereview.qt-project.org/#change,86108. BTW, any idea when your platform independent high DPI changes will make it in (or be in a working state in the review)? I would love to try having Android scale using the platform independent code. Daiwei On Tue, May 27, 2014 at 4:02 AM, Sorvig Morten <[email protected]> wrote: > On 27 May 2014, at 11:47, Daiwei Li <[email protected]> wrote: > >> Hi Morten, >> >> My understanding of your platform independent change was that it would let >> the scale factor be set by the user at runtime with an environment variable. >> Is it meant to replace all platform plugin scaling (I.e. iOS and OSX) or >> augment it? > > The QtGui scaling is meant to augment platform (plugin) scaling in cases > where the OS does not support it in a form we can use. Plugin in paranthesis > because the platform plugin does not really need to do that much work if > there is OS support. > >> >> It seems to me that Android could indeed leverage the platform independent >> scaling code by setting QT_HIGHDPI_SCALE_FACTOR. However, it would mean >> different things on Android and iOS (relative to physical resolution and >> relative to scaled resolution) and if the Android plugin relied on the env >> variable and iOS kept its platform plugin scaling. Is being able to use >> QT_HIGHDPI_SCALE_FACTOR to scale relative to the scaled resolution a >> supported use case? > > The effective scale factor (as accessed by QWindow::devicePixelRatio()) will > be the product of the OS scale factor and QT_HIGHDPI_SCALE_FACTOR. Not a > terribly common use case, but I’ve used it to test the QtGui scaling on my > MacBook. > >> >> I suppose another consideration would be setting the scale based on the >> monitor you're on. I don't know how developed Android's multi monitor >> support is, but if you wanted your application to change scale when it moved >> across different density displays, I imagine the platform plugin would need >> to do some work. > > Exactly, I think we want to add API to make it possible to control the QtGui > scaling per-window, in addition to QT_HIGHDPI_SCALE_FACTOR. This would be > needed for the KDE use case as well. As it stands today the platform plugin > can implement QPlatformWindow::devicePixelRatio(), but then Qt assumes the > plugin or the OS handles the scaling. > > All in all I see three use cases: > - the platform plugin reports a scale factor when the OS scales. > - the developer sets QT_HIGHDPI_SCALE_FACTOR asking QtGui to scale (great for > testing) > - the platform plugin/desktop environment sets a scale factor and asks QtGui > to scale. > > Screen changes on OS X works as follows: There is a screen change event. The > platform plugin then sends an expose/repaint to Qt. The code handling the > repaint will at some point call QWindow::devicePixelRatio(), which will then > report the correct value for the new screen. > > I’m not completely against adding scaling code to Android, but I would rather > see the maintenance effort go to the cross-platofrm code. If it turns you we > _do_ need the scaling code in the Android plugin for some reason, then yes > let’s do that. > > Morten > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
