Decreasing seams in scaled windows

Neil <[email protected]> Tue, 3 Mar 2026 22:08:24 -0800 (PST)
Newsgroups gmane.comp.lib.scintilla.devel
Message-ID <[email protected]>
------=_Part_25534_1726234206.1772604504687
Content-Type: multipart/alternative; 
	boundary="----=_Part_25535_1725467776.1772604504687"

------=_Part_25535_1725467776.1772604504687
Content-Type: text/plain; charset="UTF-8"

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.

This can be seen in this image with Qt 6 on Win32 with 1.25x scaling.
https://www.scintilla.org/Scale125.png

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 but 
do not eliminate them.

I believe the highest quality output will be produced when Scintilla is 
drawing to raw screen pixels and the text is scaled to match the window 
scaling factor. However, some platforms may make this difficult or 
impossible to accomplish so some improvements can be made.

[Overdraw by 1 pixel]

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. 
Extending the area of each opaque background rectangle by 1 (logical) pixel 
horizontally 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 
the window background.

If the scaling factor is less than 1.0x (0.5x?), a larger extension may be 
needed.

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.

There are problems with extending this to translucent drawing as a 
translucent drawing call will have different results when performed more 
times.

An incomplete implementation of this is available from
https://www.scintilla.org/Larger.patch

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 
margins as the implementation is currently only for EditView. 

This code is slower and could potentially cause flicker due to drawing some 
pixels multiple times. It only works in unbuffered mode and 
with SCI_SETPHASESDRAW(SC_PHASES_MULTIPLE) since it draws outside the 
strict line rectangles used in other modes.

This mode could be controlled by the application or Scintilla platform 
layer code or a combination. It is really only helpful when the window is 
scaled fractionally and this may be determined by the platform layer. It 
may change as the window is moved between screens and will be an extra 
chore for the application to manage.

Its likely that the referenced patch will grow as more elements need to 
handle it. I think the visible line end mode is one that needs to change. 
The way seamOverDraw is passed around is ugly and may have unforeseen 
effects: this could cause different results when printing, for example.

Neil

-- 
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.

------=_Part_25535_1725467776.1772604504687
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In some circumstances, when a Scintilla window is scaled by a fractional am=
ount like 1.5x or 1.25x, visual anomalies occur between filled rectangles. =
The window background may show through because the rectangles before and af=
ter or above and below only partially draw shared pixels.<div><br /></div><=
div>This can be seen in this image with Qt 6 on Win32 with 1.25x scaling.</=
div><div>https://www.scintilla.org/Scale125.png</div><div><br /></div><div>=
This was reported in some bug tracker issues and in the "Scintilla GTK 4 po=
rt" thread.</div><div>https://sourceforge.net/p/scintilla/bugs/2450/</div><=
div>In that thread, a couple of patches decrease the severity of the seams =
but do not eliminate them.</div><div><br /></div><div>I believe the highest=
 quality output will be produced when Scintilla is drawing to raw screen pi=
xels and the text is scaled to match the window scaling factor. However, so=
me platforms may make this difficult or impossible to accomplish so some im=
provements can be made.</div><div><br /></div><div>[Overdraw by 1 pixel]</d=
iv><div><br /></div><div>One technique to cover seams is to draw more than =
required to ensure that each pixel is completely covered by at least one fi=
lled rectangle call. Extending the area of each opaque background rectangle=
 by 1 (logical) pixel horizontally and vertically can achieve this. Almost =
all background drawing occurs left-to-right &amp; top-to-bottom, so each of=
 these oversized rectangles will then have a following rectangle merge nice=
ly on its leading pixel as it will only see the colour of the preceding rec=
tangle, with no trace of the window background.</div><div><br /></div><div>=
If the scaling factor is less than 1.0x (0.5x?), a larger extension may be =
needed.</div><div><br /></div><div>This technique improves over the proposa=
l to clear the whole window to a global background colour as it will work b=
etter with areas (like JavaScript in a HTML page) that use a different back=
ground colour.</div><div><br /></div><div>There are problems with extending=
 this to translucent drawing as a translucent drawing call will have differ=
ent results when performed more times.</div><div><br /></div><div><div>An i=
ncomplete implementation of this is available from</div><div>https://www.sc=
intilla.org/Larger.patch</div><div><br /></div><div>The results can be seen=
 with the same text as above.</div><div>https://www.scintilla.org/Scale125T=
weak.png</div></div><div>There are faint seams in the selection as it uses =
translucency and these will be more prominent when the selection colour dif=
fers more from the text background. There is a vertical seam between the li=
ne number and marker margins as the implementation is currently only for Ed=
itView.=C2=A0</div><div><br /></div><div>This code is slower and could pote=
ntially cause flicker due to drawing some pixels multiple times. It only wo=
rks in unbuffered mode and with=C2=A0SCI_SETPHASESDRAW(SC_PHASES_MULTIPLE) =
since it draws outside the strict line rectangles used in other modes.</div=
><div><br /></div><div>This mode could be controlled by the application or =
Scintilla platform layer code or a combination. It is really only helpful w=
hen the window is scaled fractionally and this may be determined by the pla=
tform layer. It may change as the window is moved between screens and will =
be an extra chore for the application to manage.</div><div><br /></div><div=
>Its likely that the referenced patch will grow as more elements need to ha=
ndle it. I think the visible line end mode is one that needs to change. The=
 way=C2=A0<span style=3D"color: rgb(0, 0, 0); white-space-collapse: preserv=
e;">seamOverDraw is passed around is ugly and may have unforeseen effects: =
this could cause different results when printing, for example.</span></div>=
<div><br /></div><div>Neil</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;scintilla-interest&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:[email protected]">=
[email protected]</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
scintilla-interest/5530760c-3b48-4610-8c57-0ec3fc6381den%40googlegroups.com=
?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/=
scintilla-interest/5530760c-3b48-4610-8c57-0ec3fc6381den%40googlegroups.com=
</a>.<br />

------=_Part_25535_1725467776.1772604504687--

------=_Part_25534_1726234206.1772604504687--