Post by Sorvig Morten
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."
So instead of just
(QPixmap currently represents/contains exactly one pixmap in a given resolution only)
we could (in addition) have
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
(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
(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).