[Interest] High-dpi fixing for Qt 5.5

[Till Oliver Knoll]

> Am 25.03.2015 um 14:01 schrieb Sorvig Morten <Morten.Sorvig at theqtcompany.com>:
> 
> 
>> On 24 Mar 2015, at 17:01, Till Oliver Knoll <till.oliver.knoll at gmail.com> wrote:
>> 
>> But since the QGraphicsPixmapItem is doing the drawing for me, ...
> 
> ...
> 
> To me QGraphicsPixmapItem::paint() looks like the right place to generate a new pixmap on demand - you should be able to check if painter->device()->devicePixelRatio() has changed since the previous draw call.

Exactly. Plus the (API) possibility for an application to provide the pixmaps in the required resolutions, e.g. in form of a "PixmapProvider".

QIcon for instance already has the possibility to provide a "high DPI" (aka "retina") version of a pixmap (resolution measured in "pixels"), given the desired size (measured in "points" - according to Apple lingo).

"QIcon::pixmap() has been modified to return a larger pixmap on high-dpi systems."

[http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/]

So instead of just

  QGraphicsPixmapItem::setPixmap()

(QPixmap currently represents/contains exactly one pixmap in a given resolution only)

we could (in addition) have

  QGraphicsPixmapItem::setPixmapProvider()

where the new QPixmapProvider class would work in analogy to QIcon, that is, return a QPixmap of the proper resolution ("pixels") for a given logical size ("points").

Or add the possibility (and logic) to provide a QIcon to QGraphicsPixmapItem.

Or - somehow - extend QPixmap such that multiple pixmaps (with different resolutions) could be set/stored within - with the same logic like QIcon.

The last solution would probably be the best solution, from an API point of view: existing API such as QGraphicsPixmapItem::setPixmap could remain the same. Internally however they would simply make use of the new "HiDPI capabilities" of QPixmap.

And it just "sounds funny" to read

  QGraphicsPixmapItem::setIcon

(setting a QPixmapProvider would be okay, but still confusing, since it would make the existing ::setPixmap somewhat redundant - except maybe if QPixmapProvider could inherit from QPixmap, but that sounds like a bad idea as well: a "Provider" is a "Provider", and not the "Product" itself...)


In any case, if

- QGraphicsPixmapItem was able to handle (changes in) HiDPI and
- there was a way to provide the pixmaps in the required resolutions ("@2x" etc.)

then there would be no need for an application to get informed about "resolution changes" - for that particular use case.


However it is my current understanding that QWindow based windows do get informed about screen changes, namely with

  QWindow::screenChanged()

(in the corresponding slot the devicePixelRatio can then be queried and resources rebuilt on an "as-needed" basis).

For QWidget based windows there doesn't seem to be a corresponding signal (yet - as of Qt 5.4). Even though Laszlo seems to have added at least an internal signal (ScreenChangeInternal) 6 month ago (as mentioned previously).

I would argue that there would still be cases where it would be useful for a (top-level) QWidget to get informed as soon as it has been dragged to another screen ( >= 50% of its size is on the new screen).


Cheers,
  Oliver

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150326/bf85ce7e/attachment.html>