Dark styles bounded by unexpected white lines

[Mitchell]

Hi,

One of my users is reporting an issue seeing white lines around dark style ranges on the Qt platform with KDE and Wayland (Fedora 41). I’ve attached a screenshot of what they are seeing. I’m not seeing this issue myself with Qt, but I don’t have an exact environment set up.

[Neil Hodgson]

Mitchell:L

> One of my users is reporting an issue seeing white lines around dark style ranges on the Qt platform with KDE and Wayland (Fedora 41).

May be scaling:
https://sourceforge.net/p/scintilla/bugs/2450/

Neil

[Justin Dailey]

I've seen similar issues on both Linux and Windows using Qt6+
https://github.com/dail8859/NotepadNext/issues/344

--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/scintilla-interest/27AC8124-E678-4945-BE24-9656CD8B3BB9%40me.com.

[Mitchell]

Hi,

> On Jan 9, 2025, at 5:02 PM, Justin Dailey <dail...@gmail.com> wrote:
>
> I've seen similar issues on both Linux and Windows using Qt6+
> https://github.com/dail8859/NotepadNext/issues/344
>
> On Thu, Jan 9, 2025, 4:59 PM 'Neil Hodgson' via scintilla-interest <scintilla...@googlegroups.com> wrote:
> Mitchell:L
>
> > One of my users is reporting an issue seeing white lines around dark style ranges on the Qt platform with KDE and Wayland (Fedora 41).
>
> May be scaling:
> https://sourceforge.net/p/scintilla/bugs/2450/

Thanks for the quick responses. I’ll forward this information along.

Cheers,
Mitchell

[Neil]

As mentioned on some of the issues, exposing Scintilla to the true pixel dimensions should allow this to be solved. There are likely Qt APIs to specify that the calling code is High-DPI aware and to retrieve scaling information.

If that is not possible, an overdraw technique could be tried. That would draw at least an extra logical pixel (as seen by Scintilla) at the bottom of each line. This should ensure the bottom physical pixel is completely painted but may also tint the following pixel. Drawing the next line may mix (blur) with the boundary pixel and completely paints the next pixel. Since it is drawing with the current colours (not a single global colour) this should adapt to situations where there are segments of the document with different background colours. It would only work for SC_PHASES_MULTIPLE and unbuffered drawing as other modes clip drawing to the line in logical pixels.

A scale below 100% may still cause problems as the next physical pixel may not be covered by a single logical pixel.

Drawing pixels twice will be less efficient and this addition would also increase the complexity of the drawing code.

Within each line, segment background drawing could also add an extra pixel to the right and that would work (just for the short vertical lines shown) even in SC_PHASES_TWO.

Neil

[John Ehresman]

It’s been some time since I worked with Qt’s HIDPI support, but I don’t think there’s a way to work purely in the screen pixel dimensions like I think you can in the win32 api. What you can do is render into a pixmap at the higher resolution and then paint that pixmap to the screen.

Qt implements HIDPI support through the device pixel ratio, which is the ratio of device independent coordinates to device pixels. On macOS this is typically 2.0, meaning a 200x200 device independent square renders as a 400x400 pixel square on the screen. Taking a 200x200 device independent square as an example — to draw at the higher 400x400 resolution, create a 400x400 QPixmap, set the devicePixelRatio to 1.0 and draw. Then to render to the screen, set the devicePixelRatio to 2.0 and paint the pixmap to the screen. This is what we’ve done to render high dpi icons.

I’m willing to do some experiments to try to render lines and other elements at HIDPI, but it’s been some time since I’ve worked with the core drawing code so would appreciate some pointers. Also is there a test case that shows the problem, preferably on macOS?

Thanks,

John

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/scintilla-interest/bd785523-13d2-4356-8e36-7b21322c073dn%40googlegroups.com.

[Neil Hodgson]

John:

Also is there a test case that shows the problem, preferably on macOS?

I haven't seen this in any code I have built but I mostly do Qt on Windows and may be using different versions. Just ran the Haven demo app with Qt 6.4.3 with 150% and 125% scaling on Windows 10 and there is no apparent problem. Windows has multiple legacy modes that may be covering it up though.

Even Mitchell, the first poster here, hasn't reproduced the problem.

It's unlikely to occur on macOS since (at this level) macOS uses integer scaling: a logical pixel is either a single physical pixel or 2x2 physical pixels. It appears to me that the issue occurs due to fractional scaling like 125% and 150% where logical pixels share physical pixels with other logical pixels. macOS also has display fractional scaling but that is a lower level effect which occurs after the whole screen has been drawn.

Neil

[John Ehresman]

The QT_SCALE_FACTOR environment variable can be used to adjust the device pixel ratio. Setting it to 2.1 on macOS yields a device pixel ratio of 4.2 on a typical Mac high dpi screen.

I do see some artifacts with the QT_SCALE_FACTOR set to 2.1, including in non-Scintilla widgets — the popup option menus can leave partial item outlines as the mouse moves from one item to another (I’m using the Fusion style). In Scintilla, I see the white lines below text lines when I hold to select with the mouse and move it up and down to select and deselect lines, though I haven’t investigated why it happens

John.

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/scintilla-interest/c2e51481-c69b-4234-8083-a05cd4c1ff0en%40googlegroups.com.

[Neil Hodgson]

There's been some additional discussion on a bug report.

https://sourceforge.net/p/scintilla/bugs/2450/

I don't believe that forcing the scale factor to be an integer with QApplication.setHighDpiScaleFactorRoundingPolicy is a good solution as it means the application does not respond to some values the user may prefer.

Filling the background colour does help for the reported case. The fill change could be moved out to the platform layer code that calls Paint so that it covers the margin as well as the text and can be made conditional on the scale factor being non-integral.

Neil