Hello,

with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 10000 lines takes about 18 seconds on my system. Doing the same with Lazarus 1.4.0 (FPC 2.6.4 i386-linux-gtk 2) takes about 193 ms. I cannot believe, that Lazarus 1.6 should be nearly 90 times slower than 1.4.0.

I am wondering, if this is a bug or by design?

Regards, Bernd.

unit Unit1;
{$mode objfpc}{$H+}
interface

uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls, LCLIntf;

type
    { TForm1 }
    TForm1 = class(TForm)
       Button1: TButton;
       Memo1: TMemo;
       procedure Button1Click(Sender: TObject);
    private
       { private declarations }
    public
       { public declarations }
    end;
var
    Form1: TForm1;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
var
    i: Integer;
    s: String;
    Start, Stop: DWord;
begin
    s:=
'01234567890123456789012345678901234567890123456789012345678901234567890123456789';
    Memo1.Clear;
    Start:= GetTickCount;
    Memo1.Lines.BeginUpdate;
    for i:= 1 to 10000 do begin
       Memo1.Lines.Add(s);
    end;
    Stop:= GetTickCount - Start;
    Memo1.Lines.EndUpdate;
    ShowMessage(IntToStr(Stop) + ' ms');
end;
end.

Bernd Mueller wrote

with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 10000 lines takes about 18 seconds on my system.

I can confirm that. Using 64-bit Lazarus (trunk from a week ago) with FPC 3.0.0 and LCL-GTK2. On my Intel i7-3550K CPU @ 3.50Ghz system it takes 9100ms to complete.

In comparison, with fpGUI it took 1ms.

Regards,
Graeme

El 02/11/16 a les 13:27, Bernd Mueller via Lazarus ha escrit:

Try using a TSynEdit instead of a TMemo. I did not try with lazarus 1.6, but with 1.4.4 it is 9ms vs 143 ms for a tmemo.
On windows tmemo is even slower, while TSynEdit isn't.

Bye

Thank you for your suggestion. With Lazarus 1.6, TSynEdit takes about 4 ms. But I wanted to point out, that there must be a problem with TMemo and Lazarus 1.6.

Regards, Bernd.

Luca Olivetti wrote

Try using a TSynEdit instead of a TMemo.

That's a bit of overkill in most cases, plus - as Bernd clearly point out - there is a TMemo regression bug in LCL.

Regards,
Graeme

I tested on Win 10 (using the code of the first post in this thread):

- 23 sec on Laz trunk / fpc 3.0
- 23 sec on Laz 1.6 / fpc 3.0
- 23 sec Laz trunk / fpc 2.6.4
- 2.2 sec on Laz 1.44 / fpc 2.6.4
- 1.4 sec on Delphi Berlin 10.1

Using Lazarus trunk I could get a good boost by adding the strings first to a separate stringlist which is then assigned to the memo's Lines: 1.1 sec:

procedure TForm1.Button1Click(Sender: TObject);
var
    i: Integer;
    s: String;
    Start, Stop: DWord;
    L: TStrings;
begin
    s:=
'01234567890123456789012345678901234567890123456789012345678901234567890123456789';
    L := TStringList.Create;
    try
      for i:=1 to 10000 do L.Add(s);
      Start := GetTickCount;
      Memo1.Lines.BeginUpdate;
      Memo1.Lines.Assign(L);
      Memo1.Lines.EndUpdate;
      Stop := GetTickCount;
      ShowMessage(IntToStr(Stop - Start) + ' ms');
    finally
      L.Free;
    end;
end;

original code:
990 ms with Lazarus 0.9.24 (fpc 2.2.0) on Win98/AMD Duron 1,2 GHz ;-)

Regards, Bernd.

Please create a bug report.

Mattias

El 02/11/16 a les 14:47, Graeme Geldenhuys via Lazarus ha escrit:

Maybe it's overkill, but it's necessary under windows, where tmemo is an order (or two) of magnitude slower than under Linux, even without the regression.

Bye

Luca Olivetti wrote

Maybe it's overkill, but it's necessary under windows,

Welcome to the benefits of custom components where you can easily outperform native components.

Just curious, has anybody tried the TMemo of LCL-CustomDrawn widgetset? I know the LCL-CustomDrawn components are still far from being useful in real-world applications, but how does that TMemo perform against the other native widgetsets? Or is the regression in some LCL TMemo common code?

I tried LCL-fpGUI with Bernd's code snippet, and it is dog slow, but that is because Memo.Lines.BeginUpdate..EndUpdate doesn't do anything to the fpGUI rendering performance. fpGUI has "native" Memo.BeginUpdate..EndUpdate methods (at widget level - irrespective of the internal list class used). I'll see if I can fix LCL-fpGUI's TMemo in that regard, so it calls the appropriate BeginUpdate..EndUpdate.

Regards,
Graeme

I have made a bug entry and added there a first patch (its not the final one, but its late here now). Can you check, if it fixes the speed on your OS too (I have tested only Windows 7 for now)?

http://bugs.freepascal.org/view.php?id=30851

Thank you for your feedback!

Kind regards

Michl

Michael W. Vogel wrote

I have made a bug entry and added there a first patch (its not the final one, but its late here now)

I didn't look at what exactly the patch does, but on first testing it reduced the running time from 9000+ milliseconds to 250ms. So that's definitely a step in the right direction. I also replaced the hard-coded text being added to the memo with "line <n>" where n is the value of the loop variable to confirm all lines have been added. They were.

I tested with Lazarus 1.7 r52919 FPC 2.6.4 x86_64-freebsd-gtk 2.

Regards,
Graeme

2016-11-02 19:24 GMT-03:00 Michael W. Vogel via Lazarus <

Congratulations.

I looked into it but could not spot the issue.

The Control.Text is being queried for each item added

Can you try with TextHint ''?

Seems that will need to add an aditional check for lines UpdateCount

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161102/f4b63ec5/attachment-0001.html>

Luiz Americo Pereira Camara wrote

Can you try with TextHint ''? Seems that will need to add an aditional check for lines UpdateCount

Thank you for the hints! I add a new patch (just for Windows now), it takes care about this issues. There is one nasty allocation, I have to remove, so it is not the final work. It will takes a while (or someone else has a better solution).

Kind regards

Michl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161103/62d97f13/attachment.html>

Hi,

After looking a bit at this issue
http://bugs.freepascal.org/view.php?id=30851, I have some general questions. Is the behaviour of Delphi more important or a user friendly one?
1. TextHint in Delphi is theme dependent and OS dependent (available for Windows Vista, Windows 7, or later), in Lazarus not. What is the desired behaviour?
2. TextHint in a TMemo isn't shown in Delphi (of course the property TextHint is there and can be written and readed). In Lazarus it is sometimes shown but not correct removed, if a line is inserted by code. Should TextHint generally not be shown in a TMemo or the bugs removed?

Kind regards

Michl

Michael W. Vogel wrote

1. TextHint in Delphi is theme dependent and OS dependent (available for Windows Vista, Windows 7, or later), in Lazarus not. What is the desired behaviour?

TextHint in Lazarus should be OS independent (it was decided long time ago).

The TextHint implementation should be completely rewritten. It shouldn't use the text property but paint the TextHint onto the control by itself. Windows can do that and Qt/Gtk2 should be able to do it as well (IIRC - I talked about it with zeljko in Lazarus ML). For that some new virtual paint method (PaintAfterInterface) should be introduced - that would call the widgetset dependent PaintAfterInterface method.

Ondrej

2016. 11. 04. 8:35 keltezéssel, Ondrej Pokorny via Lazarus írta:

The TextHint implementation should be completely rewritten. It shouldn't use the text property but paint the TextHint onto the control by itself.

It's good to hear! The new implementation will be included in 1.8?

Gabor

Ondrej Pokorny wrote

The TextHint implementation should be completely rewritten. It shouldn't use the text property but paint the TextHint onto the control by itself.

Very true, and using the Tex property for that is indeed a very bad idea/design. fpGUI's widgets that support TextHint does independent painting of such a hint, and obviously doesn't use the Text property for that - it works very well.

Regards,
Graeme

Ondrej Pokorny wrote

TextHint in Lazarus should be OS independent (it was decided long time ago).

Thats fine!

Thats also fine. So it can be implemented for TComboBox (as in Delphi) too. So for now, the speed and paint issue should be fixed, later the redesign.

Thank you for your hints.

Kind regards

Michl

Michael W. Vogel wrote

Thats also fine. So it can be implemented for TComboBox (as in Delphi) too.

Yes, exactly.

So for now, the speed and paint issue should be fixed, later the redesign.

If the issue is a direct cause of introducing the TextHint property then I would first do the redesign and then check the issue again. I don't have time now but next week should be OK. I thought about it already a long time ago, so I have some kind of concept - I'll check with other developers first because it will mean that TextHint will stop working - the TextHint painting methods will have to be introduced for every one widgetset.

But IMO it has to be done because the current TextHint implementation is a no-go for me (I use the WinAPI TextHint in my applications).

Graeme Geldenhuys wrote

fpGUI's widgets that support TextHint does independent painting of such a hint, and obviously doesn't use the Text property for that - it works very well.

You have the comfort of a custom-drawn widget set. The LCL has to paint over native controls, which is more complicated. Well, I like custom drawn widget sets more and more with the time :)

Ondrej

In the last trunk, the slow issue is fixed regardless of usage of TextHint in TMemo or not. Fixed also not being reset after text changed / added

Due to the way CharCase is implemented, the slow will manifest if this property is set to a value different from the default one

Some notes:
- It must be decided if TMemo.TextHint should be published. Delphi does not publish it
- The implementation of TextHint using custom paint is desired but there are no reasons to postpone the mentioned fixes since they did not require any major change
- Must be investigated the possibility of offloading the CharCase implementation to widgetset. The current implementation is far from optimal (at each change, uppercase/lowercase and reset the Text property) leading to performance and visual cluttering. Windows offers a native implementation. I don't know for others. An alternative is to uppercase / lowercase at keypress

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161104/4ed5dc58/attachment.html>

The Windows API provides a nice interface to set TextHint (and the possibility to display it if control has focus, but Text is empty). At the time I implemented it, I saw no API in GTK/QT for a TextHint-like feature.

Unfortunately TCustomEdit does not have a Canvas ;-) And I was unable to find a suitable way to paint over the control in a reliable way.

Not messing around with RealSetText/RealGetText would of course be much more disirable.

Bart

Luiz Americo Pereira Camara wrote

In the last trunk, the slow issue is fixed regardless of usage of TextHint in TMemo or not. Fixed also not being reset after text changed / added

I see that r53292, r53293 and r53296 are all about TextHint - all this code will be removed if we decide to rewrite TextHint, so it was just a waste of time :( That's why I said better to wait, just to save your energy.

Ondrej

It means exactly nothing for qt,gtk2 and carbon/cocoa, don't know about win32 but I'm pretty sure about mentioned ws.
TCustomEdit uses native WS handle, so WS is taking care about painting and it does not provide PaintEvent to TCustomEdit (sure for qt,gtk2,carbon and cocoa) - so Canvas is useless in that case. Basically, WS should draw it's control and after that LCL should get PaintEvent and event stopped, so ws won't paint it again. This is possible under Qt WS (from qt5lcl it will have property for texthint, so no need to expose paintevent to lcl) but again, not sure about others. All WS api should be checked if we need paintEvent for TextHint or WS handle have property for TextHint. Probably we'll have to support both ways to get all WS functional in case of TextHint.

zeljko

No it's not. It's pure LCL implementation and I guess that we won't be able to get it handled on WS side for all widgetsets. In that case Bart's implementation will be used.

zeljko

2016-11-04 11:32 GMT-03:00 Ondrej Pokorny via Lazarus <

The custom paint feature has no schedule. In the mean time, we need to fix both performance and behavior issues.

If/when custom paint is implemented i will be happy to see this code removed

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161104/928a19e8/attachment.html>

The current implementation opened many issues and bugs. You probably won't be able to solve some of them at all or at a reasonable effort (both for development and maintenance). E.g. try to set the edit font color while the text hint is shown:

   Edit1.Font.Color := clRed; // << execute when TextHint is visible

I remember from last year that the TextHint sometimes even wasn't correctly hidden. From that point I have never used it.

My opinion is that the current implementation of TextHint should be completely removed. Even if TextHint won't be supported on all widgetsets. Sometimes it's better to have nothing than to have a bad solution. You said Qt5 has native support, so has WinAPI, Qt4 can be solved with custom painting -> not a bad there is the question about using the native TextHint. E.g. WinAPI supports it but doesn't support custom TextHintFontColor and TextHintFontStyle - so what to do if we decide to use native TextHint support? My opinion is to keep things simple and both TextHintFontColor and TextHintFontStyle should be removed because they are superfluous. Is TextHintFontColor and TextHintFontStyle supported natively on Qt5?

Using Text and Font properties for an informative-only and inessential feature is just a rape of that properties. I mean everybody can do it in his own programs but to have such a solution on LCL level is not acceptable, in my eyes. In any case: if the TextHint property doesn't work, your programs won't stop working.

Bart wrote

The Windows API provides a nice interface to set TextHint (and the possibility to display it if control has focus, but Text is empty). At the time I implemented it, I saw no API in GTK/QT for a TextHint-like feature.

I see all you say. It was still a bad idea :)

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161106/716f0f9f/attachment.html>

No, I don't know any widgetset which supports different font color/style for texthint.

zeljko

zeljko wrote

No, I don't know any widgetset which supports different font color/style for texthint.

fpGUI does - for some years now. ;-) I also implemented a specific colour alias constant (clPlaceholderText) and alias font name, to make it easier to customise in user-defined custom style classes.

Regards,
Graeme

Marketing is the most important task in software development, so here what MSEgui provides:
http://mseide-msegui.sourceforge.net/pics/empty_text.png

Martin

Martin Schreiber wrote

Marketing is the most important task

It was for the interest of education of course. ;-)

Regards,
Graeme