Getting windows to open in same position - also IDE slowness

[heebiejeebies]

Hi all,

The IDE has been running very slowly for me for some time.  I've somehow just put up with it, but it's getting to the point now where it will soon be unusable.

I have to assume it's due to the size of my main form, which contains many different screens separated by a large TTabsheet.  The main form is around 631,000 lines long, although a lot of that is due to images.  Unless someone has a better suggestion, I'm planning to split this up into a series of smaller units and move between them without the user knowing.

Unfortunately, the form being shown does not respond to any attempts to change its position.  It always appears centred no matter what, which would be jarring if the original form was not centred on the screen when we switched forms.

This is what I have at the moment, but I've also tried getting the top and left attributes individually - nothing happens; the new form still opens centred.  Have also tried to set the position attributes from the original Form1 event; still nothing happens.  Form1Position is a TPoint variable.

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

1.   Form1.Menu := Nil;
2.   Form2.Menu := MainMenu1;
3.   Form1Position := Point(Left, Top);
4.   Form2.Show;
5.   Hide;    

Then in the OnShow event of Form2:

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

1.   Form2.Left := Form1Position.X;
2.   Form2.Top := Form1Position.Y;
3.  

[zeljko]

If you're under wayland then you cannot set position because of unimplemented wayland stuff.

[heebiejeebies]

I'm not, still using X precisely because of stupid nonsense like that with Wayland.  But seriously, that's terrible - fancy releasing half-finished software like that. 

Aaaannnnyyyywaaaay........................I have a feeling this approach is a lost cause.  Any other ideas?  Do you guys agree that it's probably the large form?  Still surprises me that in a world of gigahertz prrocessors it struggles with a file that's only 47 megabytes.  Any other suggestions as to how to approach this?

[Martin_fr]

The large file is the pascal source or the lfm file?

I have no idea how lfm file handling is implemented. Sourceeditor should do well with large file (very large files may take a bit for the initial load / files with lines longer than 1 million may be trouble)

If it is processing of a large file, it could be some string processing (copy parts of the string, changing parts) which (if done unoptimized) can lead to excessive amount of memory alloc/dealloc.

First thing to ensure is, your IDE (in case you ever recompiled it) is build without -gh / heaptrc => that slows such code further down.


But from the description it all comes down to guessing (related to the speed issues).  Run in valgrind, and see where the time goes...

The IDE has been running very slowly for me for some time.

I am somewhat assuming you refer to the form designer being slow?

Or are there other parts?

Could be the amount of handles with the WS...
Could be a lot of autosize cycles, if you have lots of autosized controls

[AmatCoder]

If you're under wayland then you cannot set position because of unimplemented wayland stuff.

Wayland does not allow specific window placement to be set but this is not unimplemented stuff. It is just the way Wayland was designed.

I'm not, still using X precisely because of stupid nonsense like that with Wayland.

That is window manager dependent.

The application can ask to the window manager to move window to the given position, but window managers are free to ignore this request even if you are using X.

[TRon]

I have to assume it's due to the size of my main form, which contains many different screens separated by a large TTabsheet.  The main form is around 631,000 lines long, although a lot of that is due to images.  Unless someone has a better suggestion, I'm planning to split this up into a series of smaller units and move between them without the user knowing.

As per your suggestion with modern hardware that shouldn't need to be an issue.

If it is, then another approach, though labour intensive, is to store your images as a resource (or imagelist) and "load" them when required.

[jamie]

Obviously you allowed the project to get away from you.

631K+ lines in a single file are ludicrous to say the least.

Create a module file and move all of the non GUI stuff there, including the image defines.

 Also, use BeginUpdate in the form when many items need to be changed and then EndUpdate when done.

 With limited knowledge of the Dbus on a unix type box or linux, i am sure the slowness could be timing, possibly?

 Also try to use SetBounds where these values get set in a single call etc.

 But in any of those cases, you need to reduce the size of that main unit, you have an apparent design flaw.

 Take advantage of using TImageList to hold images that can be shared etc.

[heebiejeebies]

The large file is the pascal source or the lfm file?

The lfm.  The pascal source is 1.9 mb/ 60,000 lines.  And yes, issue is with the designer - the source editor itself seems to be fine.  Thanks for those suggestions, I will try and see what happens - I do have quite a lot of autosized components so that could be contributing!

[heebiejeebies]

And thanks Jamie and TRon, splitting it up that way might be better than flicking between units for different screens - I'll give it a try.

[KodeZwerg]

This is what I have at the moment, but I've also tried getting the top and left attributes individually - nothing happens; the new form still opens centred.  Have also tried to set the position attributes from the original Form1 event; still nothing happens.  Form1Position is a TPoint variable.

Just to be sure, the form property "Position" is set to "poDesigned" before you assign some Left/Top values?

The LOC should have no impact about latency within IDE, but as suggested above, in general you should split the plain form "document" where your events are triggered and the actual methods into 2 or more units. (UI <-> Logic <-> Helpers/Methods/etc)

Add screenshots of IDE Form Designer and when your app is running to see how many controls you've placed. Maybe you have set some properties that fight each other ...

[Joanna from IRC]

When you say large form, I’m curious what is the total number of controls on the form?

[paule32]

My best practice on many Controls in big Form's, I coding per Hand, not per Designer.
Then, when I change a PageControl, I use Frame's, and if the fllickery are bad, I blend
some ground based Control out.

Or, I blend out, and blend in a TPanel till all Controls for the TForm or TFrame are created.
After this, I need only blend out the TPanel-Layer, and flickkery is half away.

Especially when I move TForm or scroll a TScrollBox.

[Thaddy]

These issues are usually caused by forgetting to use BeginFormUpdate/EndFormUpdate/BeginUpdate and EndUpdate. All four of those prevent excessive painting and make your GUI much snappier.
IOW: likely programmer error. In this case: as usual.
I can not state the above four methods enough in the case of painting issues.
If you do not use those four the GUI becomes slow.

In a common GUI application there are two things that can be slow:
1. Painting
2. Queries

Or both at the same time, horror.
And that is always, without exception, programmer error.

[paweld]

probably a related topic: https://forum.lazarus.freepascal.org/index.php/topic,63861.0.html

[Joanna from IRC]

I don’t know if it is applicable in this case but in some cases it is possible to reduce lag by reducing the number of controls. If this is possible it should be done.

I once had a color picker with hundreds of colored shapes and zaherdirkey told me to just draw the shapes in a paintbox instead of using shape controls.

The lag problem was solved by just detecting where mouse event happened instead of using hundreds of shape controls.