Re: Decreasing seams in scaled windows

Hi Neil,

> On Jun 15, 2026, at 7:56=E2=80=AFPM, Neil Hodgson <scintilladotorg@gmail.=
com> wrote:
>=20
> An updated version is available that fixes problems with scrolling and
> position+size of calltips and autocompletion.
>=20
> A ScaleTechnique property was added with values
> SCALE_TECHNIQUE_DEFAULT=3D0, SCALE_TECHNIQUE_PIXEL_ALIGNED=3D1 controlled
> with a SCI_SETSCALETECHNIQUE API.

I like this! Thank you for adding it.

I found a bug though: on macOS when I use the API to change to PIXEL_ALIGNE=
D scaling, all drawing shrinks by half (text is tiny). I have to increment =
and decrement zoom level to make drawing fine again. Similarly, when I use =
the API to go back to DEFAULT, all drawing multiplies by two (text is huge)=
. When I decrement and increment zoom level, drawing is fine again.

I imagine you are already aware, but just in case, some markers need to adj=
ust their drawing to accommodate the new scale tech. For example, I am usin=
g box tree fold margin markers. When I double my margin size from 12 to 24 =
with PIXEL_ALIGNED, I am getting the expected size, but the inner =E2=80=9C=
-=E2=80=9C and =E2=80=9C+=E2=80=9D symbols pretty much touch the boxes when=
 they should be inset more (probably double).

I will continue to play with this, but so far so good.

Cheers,
Mitchell

>=20
> The ScaleTechnique property may get additional enumeration values or
> modifying bit flags with future refinements. This feature is marked
> provisional so may change.
>=20
> While the calltips and autocompletion lists are positioned under the
> caret, they do not always flip above the caret when there is no room
> below. This is because scaling is not consistently taken into account
> when checking the bottom of the screen or window.
>=20
> Autocompletion lists were made slightly wider as text could be
> truncated with ... in some cases. This is from converting coordinates
> that are scaled by a fraction to integers and there may be other
> instances with similar issues.
>=20
> The patch changes the location of the output shared libraries to be in
> scintilla/bin as they were often in
> scintilla/qt/ScintillaEditBase/bin. Newer versions of qmake (or Qt
> Creator) seemed to use a different base or current directory when
> building and this caused problems for downstream projects like Haven
> that were coded to previous behaviour.
>=20
> Haven was updated as https://www.scintilla.org/HavenScale4.zip to
> match the changes in the patch.
>=20
> Patch attached.
>=20
> This may be committed to the main repository for the next release, so
> anyone who thinks it may cause problems or want changes should speak
> up now.
>=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/CACWkrTgsnwcr_8C53NfpBfFptT%2B5dURNTE3vHWJpG2i6MumVhQ%40mail.gmai=
l.com.
> <QtScaleH.patch>

--=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/EFADB2E3-FFE6-4FC9-8CAD-E9564D3EB8E9%40foicica.com.