Re: Decreasing seams in scaled windows

Hi Neil,

> On May 24, 2026, at 11:34=E2=80=AFPM, Neil <[email protected]> wr=
ote:
>=20
> There were some more problems on current Wayland with the popups reportin=
g a devicePixelRatioF of 2.0 when the system scale was 1.5 or 1.33. Its pos=
sible this is an initialization issue with windows not knowing an accurate =
scaling factor before they receive a set scale message. It was fixed by usi=
ng the devicePixelRatioF of the main Scintilla window in the attached patch=
.
>=20
> Mitchell:
>=20
> I like the indicators that I see without the patch. Having multiple new s=
cale-specific indicators doesn=E2=80=99t sound ideal.
>=20
> It's more likely you will be able to replace Diagonal with a single new D=
iagonalProportionalToDescender (or similar name) that implements a particul=
ar style of scaling diagonals. If there are different opinions on the best =
technique to use then there could be more than one Diagonal*.

That=E2=80=99s precisely what I=E2=80=99m concerned about. I use diagonal a=
nd squiggly indicators. They would each need their own scaled versions, pos=
sibly with more permutations. My application would have to pick an indicato=
r based on detected scaling, etc. Right now, Qt already draws things correc=
tly, even in my HiDPI Ubuntu 24.04 VM with 200% scaling.

> A constraint here is that downstream Windows projects have been scaling f=
or 6 years and shouldn't have their appearance modified in ways that they m=
ay not like or want.

I think I could say my Mac project has been scaling for 6 years :) Or maybe=
 I misunderstand your meaning.

> I increased my margin width using your new patch, but the markers remaine=
d the same, small size. Do I need to implement some sort of client-side sca=
ling?
>=20
> It is likely you will have to perform some scaling yourself.

Okay, so another client-side branch based on whether or not the application=
 is running on a HiDPI display.

> I did run into a strange issue with a Scintilla view that is normally 1 l=
ine high is now 2 lines high. However, I set the height using the SCI_TEXTH=
EIGHT, so I suspect Scintilla is reporting a new scaled height. Either I ha=
ve to divide by two, or Scintilla (or its Qt platform) needs to do another =
computation somewhere.
>=20
> I'm not sure. There are really two scales working in the code: graphics a=
nd windowing with window coordinates not being scaled.

That=E2=80=99s what I was afraid of. Now I need to become an expert to know=
 the difference between what units Scintilla=E2=80=99s APIs are reporting, =
and what units the Window toolkit is reporting.

> I would like some sort of control to disable scaling and keep the default=
 drawing Scintilla Qt is doing on my Retina and 4K display (I assume macOS =
is doing 200% scaling for both). When I have time, I can enable scaling and=
 then identify and report any issues I find, as I am now. Right now it feel=
s like I=E2=80=99m going to run into a lot of small things over time rather=
 than all at once. I=E2=80=99d be more comfortable with the fallback to dis=
able and keep the current drawing.
>=20
> I have been working on this but scaling occurs in many places and the 'sc=
aled' control property needs to be distributed and kept current.

I understand. It=E2=80=99s a hard issue with a non-zero maintenance burden.

Ultimately I will accept and adjust to whatever changes you make. I=E2=80=
=99m just offering my feedback now at this early stage for what it=E2=80=99=
s worth.

Cheers,
Mitchell

--=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/96031856-CB8D-45BE-9B32-3ADC515E511B%40foicica.com.