Lazarus Release Candidate 2 of 2.2.0

[robert rozee]

attached is a revised version of wp's code, with fixed StaticText font (was default, now Courier New), and slightly changed PaintBox code:

Code: Pascal  [Select][+][-]

1. procedure TForm1.PaintBox1Paint(Sender: TObject);
2. var I:integer;
3.     W:integer;
4. begin
5.   Paintbox1.Canvas.Brush.Color := clRed;
6.   Paintbox1.Canvas.FillRect(0, 0, Paintbox1.Width, Paintbox1.Height);
7.   Paintbox1.Canvas.Brush.Color := clWhite;
8.   Paintbox1.Canvas.Font.Assign(Label1.Font);
9.   Paintbox1.Canvas.Textout(4, 4, 'This is underlined text.');
10.   Paintbox1.Canvas.Font.Color:=clWhite;
11.   W:=PaintBox1.Canvas.TextWidth('##');
12.   for I:=0 to 4 do                                                      // 20 characters in total...
13.   begin
14.     Paintbox1.Canvas.Font.Style:=[fsUnderline];                         // two characters underlined
15.     Paintbox1.Canvas.Textout(4+(2*I*W)  , 40, '##');
16.     Label8.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));
17.     Paintbox1.Canvas.Font.Style:=[];                                    // two characters NOT underlined
18.     Paintbox1.Canvas.Textout(4+(2*I*W)+W, 40, '##');
19.     Label9.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));
20.   end;                                                                  // repeated 5 times
21. end;

the paintbox background is now red, so you can see the of boundary what Textout produces. also added is another line of text, with white text on a white background, highlighting the cases where the height of the text is different when underlining on/off. Note the values for TextHeight do not change, while the height of the output does. Also note (in magnified section, below) where the underlining starts one pixel offset from the left.

i vaguely feel that a good portion of the problem is something outside of Lazarus, when the underline is defined as being located below the bottom edge of the character cell. the problem doesn't seem to manifest in Linux.


cheers,
rob   :-)

[wp]

There are two ways to draw text with Lazarus:

• Canvas.Textout /Canvas.TextRect: Debugging into the LCL you can see that it finally calls Windows.ExtTextOutW.
• DrawText(handle, ...): This finally calls Windows.DrawTextW

As the attached demo shows, the underscore issue occurs only with DrawText, not with Canvas.TextOut.

TLabel.Paint finally calls the DrawText method. I am aware that it has advantages in calculating the size of the bounding rectangle when wordwrapping is allowed. Maybe this was the reason why the creators of the LCL chose this method.

This leads to the idea that the reason for the issue is in Windows, and this is confirmed when I do the same test in Delphi XE10.3.3 which shows exactly the same behaviour.

I could imagine that the vertices of the font glyphs are defined either by floating point numbers or by large integers later scaled to the destination font size. Depending on how this is done exactly there may be round-off errors by one pixel which eventually may show or hide the underscore line.

Sounds bad...

On the other hand, as a remedy, we could increment the bottom of the rectangle returned by the DrawText method when DT_CALCRECT is included in the flags.

Since this is needed for Windows only, I'd recommend that you try the following steps:

- Load the file lcl/interfaces/win32/win32winapi.inc (You should make a backup copy of the changed file so that you can restore the original behaviour).

- Find the procedure TWin32WidgetSet.DrawText.

- Towards its end there is block "if lf.lfItalic > 0". Put the following code before this "if". It is supposed to move the bottom of the calculated bounding rectangle of the text by one pixel to avoid clipping of the underscore line.

Code: Pascal  [Select][+][-]

1.     if lf.lfUnderline<>0 then
2.       inc(Rect.Bottom);

- Rebuild the IDE and run your tests again

- Report back whether it fixes the issue and whether you see any side effects (it seems to work for me).

[prof7bit]

Has the naming scheme of the branch tags changed?

previosly it was

[main|t-fixes]_<version>

now with RC2 it has become

lazarus_<version>[_RCx]

The space in the about box was already quite small for a full git description, but now with this overly long tag name it has become very unreadable. I personally find "lazarus-" in the tag name (and thereby in the revision-"number") quite redundant, because what else would one expect to find in the Lazarus repository? Generally I believe the tag names should follow some consistent scheme that doesn't change with every release candidate, and they should not carry redundant information.

Was this new tag name merely an accident or was there really a naming scheme change? I suspect the former, but fortunately the tags can still be changed afterwards without impacting the revision hash or rewriting history.

[Martin_fr]

No, they haven't changed.

Here is how the go (and you can look at the fixes_2_0 branch (and others), and see it's the same.

1) The very first commit is tagged: "main-0_0"

2) Each time a fixes branch diverges (each time the revision number in "main" changed, e.g from 2.1 to 2.3)
- the fixes branch's very first commit is tagged "t-fixes-n_n"
   (the "t-" is to distinguish from the branch name)
- the main branch is tagged: "main-n_n"

3) Each time a release is made from fixes (including RC)
a new tag is added to fixes "lazarus-n_n_n"  (one "_n" less for the first release on the branch)
(There was a discussion to make it "release-n_n_n", but that would not make a diff in the length of the tag)

This had been forgotten for the RC1 => therefore it had not been seen then.
(That RC1 tag should still be added...)

4) Feature branches (if long living) may also have a tag on their very first commit, so they do not report "main-n_n".

[Martin_fr]

Maybe it can be shortened it the display....
Don't know.

[zed]

Lazarus takes a lot of RAM (more then 2Gb) when I start debugging (with FpDebug) small HelloWord. Is it normal?

Reproduce:
1. Start Lazarus (it automatically loads previous simple console application) -> 120 MB of RAM
2. Set one breakpoint and press F9
3. Debugger stopped at breakpoint -> almost 2GB of RAM already allocated!

Windows 8.1, x64, Lazarus with additionally installed ancordock components.

With GDB debugger there is no such RAM issue.

[wp]

For me (Win 11/64 bit, Laz 2.2.0RC2/fpc3.2.2/64 bit): empty form with button and ShowMessage(..) in its OnClick handler, breakpoint at ShowMessage --> 106 MB
(fpdebug, almost no additional components)

[Martin_fr]

I would not expect that much RAM to be used...

FpDebug will load the debug info (dwarf) from the compiled exe. Even for a project like the IDE, with a lot of code, that is only about 200 or 300MB. Nothing close to a GB.
Also it will build some indexes, they are but a fraction of the info itself.

Further the dwarf is loaded by "mapping" the file to mem. So windows will only load what is needed.

==> So unless your compiled exe is over 1GB on disk....

Tested with "git main"

For a hello word console, running in the debugger I get about 150MB. (including what was used before debugging)

Debugging the IDE within the IDE, I get 900 MB.

There may be a bit more, if I force re-compilation, or if I had another project open before.

If you use gdb, then some of that mem will be used by gdb, instead of the IDE....

Do you more info, maybe an example?

[zed]

Record a video: https://disk.yandex.ru/i/rkTw1IFSLnA2hA

Project with all files attached.

[prof7bit]

a new tag is added to fixes "lazarus-n_n_n"  (one "_n" less for the first release on the branch)
(There was a discussion to make it "release-n_n_n", but that would not make a diff in the length of the tag)

I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.

[Martin_fr]

Strange, I get 40 MB use (60MB as peak use).

I tried both the 64bit (as you seem to have) and the 32bit release of the RC2.
Even changed the FpDebug limits.
And I installed AnchorDocking (which I normally don't use).

I could not get it up. Rebuilding the IDE, uses 800 MB, but then it restarts, and goes back to normal usage.

I assume, you checked mem usage, after "building", before "running" => so the increase indeed happened when you did run your app?


Do you have any Antivirus software that may get hooked into the IDE (afaik AV can load into other processes)

In the "task manager" go to the "details" page, and add the column "memory (shared work set)".
How much of the 2 GB are shared?

Can you install the IDE again ? You can do a "secondary install" to a diff directory, using a diff config dir.

Then, with that IDE, as it comes => no packages installed, no anchor dock, on other packages => try again?
(You can change the fpdebug options).

[Martin_fr]

I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.

The "lazarus" prefix (as I said, "release" would do too, but we carried "lazarus" from the svn days) is an indicator that this tag marks a release.
If we do add other tags, for whatever other reasons in future, then we need to distinguish.

Already, not every tag is a tag for a release.
Tags starting with main and t-fixes mark the first commit after branch diverge.
But those tags, also look like version numbers. So they need to be distinguished from release tags.


The problem is not the length of the tag. in "git log" imho its fine (but you may see that different).

In the about dialog it may want to be shortened. The long text could be a hint, and could be in the copy to clipboard.

At the moment though, I want look into this myself. If someone else from the teams spots it here, they may respond and may have an idea...
Not all team members do read here though...

[zed]

I assume, you checked mem usage, after "building", before "running" => so the increase indeed happened when you did run your app?

Yes. There is no memory growing after build and even "Run without debugger". It grows only when I run app with F9 (even without any breakpoint). Attached screenshot with detailed memory info.

I will try install new copy of Lazarus and let you know.

[zed]

Secondary installation without additional packages works fine.

The bug appears when I install Anchordocking, Anchordockingdsgn, DockedFormEditor and build IDE with "Optimized IDE" profile. Then I try rebuild IDE with "Normal IDE" profile and the bug is gone! But lazarus.exe size increased from ~30MB up to 300MB...

[wp]

But lazarus.exe size increased from ~30MB up to 300MB...

This is the debug information. You can get rid of it by calling "strip -s lazarus.exe" where strip is in the same folder as fpc.exe.