Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-07 06:39, Martin Schreiber via Lazarus wrote:
> Marketing is the most important task

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

Regards,
  Graeme

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Martin Schreiber via Lazarus]

On Monday 07 November 2016 00:39:51 Graeme Geldenhuys via Lazarus wrote:
> On 2016-11-06 15:45, zeljko via Lazarus 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.
>
Marketing is the most important task in software development, so here what 
MSEgui provides:
http://mseide-msegui.sourceforge.net/pics/empty_text.png

Martin
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Ondrej Pokorny via Lazarus]

On 04.11.2016 16:18, zeljko wrote:

On 11/04/2016 03:32 PM, Ondrej Pokorny via Lazarus wrote:

On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus 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.


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.


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 start at all.


Then 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.



On 04.11.2016 14:28, Bart via Lazarus 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
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[zeljko via Lazarus]

On 11/04/2016 02:28 PM, Bart via Lazarus wrote:

On 11/4/16, Ondrej Pokorny via Lazarus  wrote:


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.


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.


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


--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Ondrej Pokorny via Lazarus]

On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus 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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Luiz Americo Pereira Camara via Lazarus]

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
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Ondrej Pokorny via Lazarus]

On 04.11.2016 10:38, Michael W. Vogel via Lazarus 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).


On 04.11.2016 10:11, Graeme Geldenhuys via Lazarus 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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-04 07:35, Ondrej Pokorny via Lazarus 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

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Gabor Boros via Lazarus]

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Ondrej Pokorny via Lazarus]

On 03.11.2016 22:46, Michael W. Vogel via Lazarus 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).

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?


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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Michael W. Vogel via Lazarus]

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Michael W. Vogel via Lazarus]

Am 03.11.2016 um 00:27 schrieb Luiz Americo Pereira Camara via Lazarus:

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
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-02 22:24, Michael W. Vogel via Lazarus 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 " 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

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Michael W. Vogel via Lazarus]

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


Am 02.11.2016 um 20:26 schrieb Graeme Geldenhuys via Lazarus:

On 2016-11-02 18:43, Luca Olivetti via Lazarus 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



--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-02 18:43, Luca Olivetti via Lazarus 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

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Luca Olivetti via Lazarus]

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

On 2016-11-02 13:36, Luca Olivetti via Lazarus 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.


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
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Werner Pamler via Lazarus]

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 1 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;
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-02 13:36, Luca Olivetti via Lazarus 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

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Bernd Mueller via Lazarus]

On 11/02/2016 02:36 PM, Luca Olivetti via Lazarus wrote:


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.



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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Luca Olivetti via Lazarus]

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

Hello,

with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 1
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.


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
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Graeme Geldenhuys via Lazarus]

On 2016-11-02 12:27, Bernd Mueller via Lazarus wrote:
> with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 1 
> 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

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6

[Bernd Mueller via Lazarus]

Hello,

with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 1 
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 1 do begin
  Memo1.Lines.Add(s);
   end;
   Stop:= GetTickCount - Start;
   Memo1.Lines.EndUpdate;
   ShowMessage(IntToStr(Stop) + ' ms');
end;
end.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus