See attachment for screenshot. Is this a common issue or usage issue?
I noticed that PRectangle's documentation says:
PRectangle follows the Mac / Windows convention of not including its bottom and right sides
instead of including all its sides as is normal in GTK.
Then I noticed we directly use the PRectangle to fill the color:
void SurfaceImpl::FillRectangle(PRectangle rc, Fill fill)
{
GetPainter()->fillRect(QRectFFromPRect(rc), QColorFromColourRGBA(fill.colour));
}
...which uses QRectFFromPRect simply convert a PRectangle to QRect. Thus, for me, using the following change could fix this issue (the fix is adding + 1):
inline QRectF QRectFFromPRect(PRectangle pr)
{
return QRectF(pr.left, pr.top, pr.Width() + 1, pr.Height() + 1);
}
So my question is: Is that a bug or I'm actually using it in a wrong way?
Feel free to let me know if you need any additional information. Thanks!
Gary.
This is likely due to scaling. See [#2450].
Related
Bugs: #2450
Yeah it indeed look like the same issue as #2450, while I don't think go with
setHighDpiScaleFactorRoundingPolicyis a sane way to fix this issue...https://sourceforge.net/p/scintilla/bugs/2450/#e379: Adding
surface->FillRectangle(rcTextArea, Fill(vsDraw.styles[StyleDefault].back));just above// Loop on visible linesinEditView.cxxalso works! While the left line number margin still have thin line but it's at least usable :)So does it mean
QRectFFromPRectactually don't need to add+1when converting PRectangle to QRect?Last edit: Gary Wang 2026-02-26
Scaling seams are a difficult issue to solve unless Scintilla performs its own scaling as the Win32 platform does with
dpiAwareenabled.Adding the above extra FillRectangle is only a partial fix in some circumstances. It doesn't, for example, fix most selection drawing or where background colour is used a lot to convey meaning.
There are better patches in this mailing list thread allowing the application to set a background colour and remove seams between runs of the same background colour.
https://groups.google.com/g/scintilla-interest/c/_ZgpYuzZdoU
The current code is accurate and +1 will likely cause more drawing problems.
Adding 1 to the bottom of background rectangles so they overlap the next line may be tried but it complicates the implementation and will be slower.