Re: Decreasing seams in scaled windows

Hi Neil,

> [snip]
>=20
> See attached noscale.png and yesscale.png images. The arrows in the latte=
r point to the weird things I=E2=80=99m seeing:=20
> - hard to see indicators
>=20
> Most indicators do not scale. IndicatorStyle::Diagonal, in particular, tr=
ies to fit 3 pixel high underlines in the text descender area which is quit=
e tight so may result in clipping.
>=20
> With 'noscale.png' macOS Retina scaling, 3 pixels =3D 6 physical pixels w=
hich looks quite good. 'yesscale.png' is using 3 physical pixels so looks t=
oo faint. A new indicator (which I think should have a new name) could be i=
mplemented in various ways. The descender height could determine the height=
 and spacing of the diagonal lines although that will decrease density. The=
 stroke width could be made wider although it should probably remain an int=
eger - a 1.5 pixel wide line here produces an less distinct blob.

I like the indicators that I see without the patch. Having multiple new sca=
le-specific indicators doesn=E2=80=99t sound ideal.

>  - hard to see margin symbols
>=20
> The margins are specified in physical pixels so the application should (i=
f desired) scale the argument to SCI_SETMARGINWIDTHN. The reason Scintilla =
doesn't automatically scale these is that symbol margins are particularly s=
ensitive to tweaking and I wanted applications to control exactly how wide =
margins are. SciTE provides a '$(scale)' function that may be used until mo=
re control is wanted.

I increased my margin width using your new patch, but the markers remained =
the same, small size. Do I need to implement some sort of client-side scali=
ng?

>  - too large autocompletion window
>=20
> [snip]
>=20
> A QtScale7.patch that includes these changes is attached.

I confirm this is fixed.

I did run into a strange issue with a Scintilla view that is normally 1 lin=
e high is now 2 lines high. However, I set the height using the SCI_TEXTHEI=
GHT, so I suspect Scintilla is reporting a new scaled height. Either I have=
 to divide by two, or Scintilla (or its Qt platform) needs to do another co=
mputation somewhere.

>  I looked at the documentation to try and find an option to set scaling, =
but I couldn=E2=80=99t find it. I assume the patch is supposed to detect an=
d apply scaling via the devicePixelRatio() computations.
>=20
> Yes, this is trying to be automatic, at least for basic uses. There could=
 be an API either to set a scaling factor or just to control whether the sc=
aling is enabled.

I would like some sort of control to disable scaling and keep the default d=
rawing 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 t=
hen identify and report any issues I find, as I am now. Right now it feels =
like I=E2=80=99m going to run into a lot of small things over time rather t=
han all at once. I=E2=80=99d be more comfortable with the fallback to disab=
le and keep the current drawing.

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/E61E3C98-4C8A-4D26-9B74-EDCB12C45C47%40foicica.com.