I updated https://bugreports.qt-project.org/browse/QTBUG-23870 with a longer description on Image/Pixmap drawing.
If you resize manually you need to know if you are targeting a 1x or 2x display. Better to just specify the target rect and let Qt resize the image for you - Qt can do this if the image as a correctly set DPI scale factor. Patch is still not ready, sorry! Morten ________________________________________ From: P Bai [[email protected]] Sent: Monday, September 24, 2012 8:59 PM To: Sorvig Morten; [email protected] Subject: Re: [Development] Retina display support Thank you, Morten. So will QPixmap/QImage handle hiDPI automatically? I mean, for example, how does it handle resize? If I load an image file as QImage, and then resize it so that I can draw in a QRect, will the resized QImage actually have 2x resolution in HiDPI mode? Also I still will be able to directly access the pixel data in HiDPI mode, right? And of course when do you think we can expect a working patch?:-) I can't wait to make my application retina ready! Thank you again, P ----- Original Message ----- From: Sorvig Morten <[email protected]> To: "[email protected]" <[email protected]> Cc: Sent: Monday, September 24, 2012 6:02 AM Subject: Re: [Development] Retina display support On 21 Sep 2012, at 15:30, P Bai <[email protected]> wrote: > Thank you, Eike. From what I read in the codereview, a function to get the > scale factor qt_mac_get_scalefactor() is available as a patch, but > QPixmap/QImage HiDPI support is still a WIP. Does that mean even if I were > able to detect HiDPI mode, I still can't do anything until QPixmap/QImage > support becomes available. Is that right? The patches are still not ready, but I can give you an idea of how it's going to work: As you know there is a point/pixel split. Screen/window/widget/event geometry is in points. QPixmap and QImage sizes are in pixels. On high-dpi screens there is a 1:2 mapping between points and pixels - point geometry does not change. You can mostly keep working in points as before and ignore the scale factor, except when dealing with raster graphics. There will be a (public) function for accessing the scale factor, most likely qt_mac_get_scalefactor() in Qt 4 and perhaps a QScreen/QWindow property in Qt 5. I say perhaps because it's complicated: get_scalefactor needs to know the screen in question, but we don't always have that information in Qt (for example deep in style code). For QPixmap/QImage my current approach is to add a dpiScaleFactor property to both classes, which is typically set to 2.0 to indicate high-dpi raster content. I've experimented with adopting the "@2x" file name convention when loading images from files, this seems to work well. QIcon::pixmap() will also be modified to produce a high-dpi pixmap when appropriate. The plan is that Qt 4 will support painting OF high-dpi images to screen, and that Qt 5 will (in addition) support painting ON high-dpi images using a scaled painter. The latter is required since Qt 5 uses the raster graphics system. There is one behaviour change to be aware of: With the addition of dpiScaleFactor it is now an error to calculate layouts directly from pixmap and image sizes. The correct way is to divide the size by the scale factor. For example, a 2x 64x64 pixmap should be 32x32 points on screen. This is a behaviour change wich has the potential to break user code, so I think we'll need to have an opt-in mechanism here. For OpenGL you can request a 2x pixel buffer by setting a flag. Qt should provide a similar option to apps. - 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
