Re: Decreasing seams in scaled windows

John Ehresman <[email protected]> Thu, 5 Mar 2026 15:40:31 +1100
Newsgroups gmane.comp.lib.scintilla.devel
Message-ID <[email protected]>
Apologies for not looking into this sooner. I think Qt can render to the ra=
w screen or device pixels (or at least the backing pixmap that Qt draws to =
before sending to the screen).

The way to simulate / adjust the scaling factor is to use the QT_SCALE_FACT=
OR environment variable; e.g QT_SCALE_FACTOR=3D1.5 testprogram=20

One way to draw to raw pixels is to render to a full size pixmap, set the d=
evice pixel ratio to match the widget, then render the pixmap to the widget=
.

It also may be possible to set the scale on a painter to 1 / device-pixel-r=
atio and then draw.

I may be able to try to fix this in scintilla, but it probably won=E2=80=99=
t be immediately.

John

> On Mar 4, 2026, at 5:08=E2=80=AFPM, Neil <[email protected]> wrot=
e:
>=20
> In some circumstances, when a Scintilla window is scaled by a fractional =
amount like 1.5x or 1.25x, visual anomalies occur between filled rectangles=
. The window background may show through because the rectangles before and =
after or above and below only partially draw shared pixels.
>=20
> This can be seen in this image with Qt 6 on Win32 with 1.25x scaling.
> https://www.scintilla.org/Scale125.png
>=20
> This was reported in some bug tracker issues and in the "Scintilla GTK 4 =
port" thread.
> https://sourceforge.net/p/scintilla/bugs/2450/
> In that thread, a couple of patches decrease the severity of the seams bu=
t do not eliminate them.
>=20
> I believe the highest quality output will be produced when Scintilla is d=
rawing to raw screen pixels and the text is scaled to match the window scal=
ing factor. However, some platforms may make this difficult or impossible t=
o accomplish so some improvements can be made.
>=20
> [Overdraw by 1 pixel]
>=20
> One technique to cover seams is to draw more than required to ensure that=
 each pixel is completely covered by at least one filled rectangle call. Ex=
tending the area of each opaque background rectangle by 1 (logical) pixel h=
orizontally and vertically can achieve this. Almost all background drawing =
occurs left-to-right & top-to-bottom, so each of these oversized rectangles=
 will then have a following rectangle merge nicely on its leading pixel as =
it will only see the colour of the preceding rectangle, with no trace of th=
e window background.
>=20
> If the scaling factor is less than 1.0x (0.5x?), a larger extension may b=
e needed.
>=20
> This technique improves over the proposal to clear the whole window to a =
global background colour as it will work better with areas (like JavaScript=
 in a HTML page) that use a different background colour.
>=20
> There are problems with extending this to translucent drawing as a transl=
ucent drawing call will have different results when performed more times.
>=20
> An incomplete implementation of this is available from
> https://www.scintilla.org/Larger.patch
>=20
> The results can be seen with the same text as above.
> https://www.scintilla.org/Scale125Tweak.png
> There are faint seams in the selection as it uses translucency and these =
will be more prominent when the selection colour differs more from the text=
 background. There is a vertical seam between the line number and marker ma=
rgins as the implementation is currently only for EditView.=20
>=20
> This code is slower and could potentially cause flicker due to drawing so=
me pixels multiple times. It only works in unbuffered mode and with SCI_SET=
PHASESDRAW(SC_PHASES_MULTIPLE) since it draws outside the strict line recta=
ngles used in other modes.
>=20
> This mode could be controlled by the application or Scintilla platform la=
yer code or a combination. It is really only helpful when the window is sca=
led fractionally and this may be determined by the platform layer. It may c=
hange as the window is moved between screens and will be an extra chore for=
 the application to manage.
>=20
> Its likely that the referenced patch will grow as more elements need to h=
andle it. I think the visible line end mode is one that needs to change. Th=
e way seamOverDraw is passed around is ugly and may have unforeseen effects=
: this could cause different results when printing, for example.
>=20
> Neil
>=20
> --=20
> 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 [email protected].
> To view this discussion visit https://groups.google.com/d/msgid/scintilla=
-interest/5530760c-3b48-4610-8c57-0ec3fc6381den%40googlegroups.com.

--=20
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 e=
mail to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/scintilla-i=
nterest/ED4C30EA-C76E-4D91-B33C-3065799F6C0B%40wingware.com.