> Am 25.03.2015 um 14:01 schrieb Sorvig Morten <[email protected]>: > > >> On 24 Mar 2015, at 17:01, Till Oliver Knoll <[email protected]> >> 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
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
