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.