Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-114860

Inconsistency in widget drawing between retina and regular display

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • P3: Somewhat important
    • None
    • 5.15.10, 6.4.3
    • None
    • macOS 10.15.7, retina display
    • macOS

    Description

      I encountered an issue related to high DPI support on macOS that I find quite interesting. We discovered an inconsistency in the way a widget was drawn between a retina display and a regular display.

      I am on a macbook pro with macOS 10.15.7, a retina display and a device pixel ratio of 2.

      We have a QFrame that contains a waveform with three cursors, each of them being 1 pixel wide. These cursors serve different purposes: one for audio, one for mouse positioning, and one for signal calculation. This setup had been functioning well for decades until we introduced high DPI support. We started noticing phantom cursor positions. In the example below, I have recreated this issue with a single cursor (using '#define SIGNAL_VERSION 1' in the attached example).

      The problem becomes particularly apparent when using a dual-screen setup with a regular display. If you move the window from one screen to another, you can observe the cursor working correctly on the regular display but behaving differently on the retina display.

      Our approach involves passing to update() a region consisting of two adjacent pixel positions every time a redraw is requested. The first is the last position of the cursor to be erased, the second is the next position of the cursor to be drawn.

      To investigate the issue further, we created two rows (using '#define SIGNAL_VERSION 0' in the attached example): the top row contains the cursor, and the bottom row is used to color the entire width of the region received by the paintEvent method.

      From the image, it can be seen that the cursor is drawn on two physical pixels in the middle of the four physical pixel wide paintEvent region, which is not what we expected. This behavior disrupts the logic of “erasing pixel” next to the “drawing pixel”.

      To work around this problem, we extended the erasing region, yet I believe an inconsistency like this might also be of interest to you.

       

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            sorvig Morten Sørvig
            steph-g Stéphane Gaydier
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Gerrit Reviews

                There are no open Gerrit changes