Slowness on moving large selection

kgiddings

(Copied from newsgroups as no response)

This is now a huge problem for us - the amount of time that a user has to wait is not acceptable to them as it can take 30 seconds or more from the user starting the drag to the point where the wireframing is done and the drag actually starts.

The system is used to create process control forms for ship control systems and one object like (eg) a ship's pump can be made up of a lot of components.  The user will often need to move all of these components at once to reposition the pump to add additional components.

Do the handles really need to be hidden?  Can they not be moved with the components or would that be just as slow? We desperately need to
find a solution for this.

I commented out the line (FSelCtrls.SetVisible(False) ) that hides the handles,  and the move is now almost instant and I can't see any problems so far. (Except of course the handles are still visible which isn't a problem for us).

Regards
Keith.

balabuev

Can you send me a small demo project (without any non standard dependencies, please). I'll try to profile it and may be, I'll find the bottleneck...

kgiddings

Here is a small sample project created with the ide2 demo.  Try selecting all the components on the form and then moving them with the mouse and with the keyboard arrows to see the problem.

Attachments don't seem to be working?

Sent via email.

balabuev

Please send it to balabuev@gmail.com...

kgiddings

Any luck?

balabuev

Hi,

I've made all I can. Try to update the sources from SVN. I think that making it eve faster is not possible.

kgiddings

Hi Eugene, 

I don't have access to svn as I only have the IDE tools.  Is it possible for you to email me the changes so I can try them,  or will they be part of an update in the near future?

Regards
Keith

Rafael Maricca (LMD)

Will be part of our regular service releases.

Regards,

Rafael Maricca

LMD Innvative

kgiddings

Hi Rafael - can you give me an idea of when?  This problem is stopping the release of the product. I tried to select a single component in a DFM with around 600 components in it and due to the code that is called as part of the notification to the LMDComponentTree (_AssociateNode in RecreateSprigs) it takes 5 seconds before you can do anything else.  I need to know if this kind of problem is fixed or if I need to rethink parts of the interface and I can't really wait a long time to know.

Regards
Keith

kgiddings

BTW to get an idea of the kind of DFM we are editing take a look at this image of the software - this dfm has 650 components on it.

http://gpthame.com/picture_library/Ballast.png

balabuev

Hi,

> and due to the code that is called as part of the notification to the LMDComponentTree (_AssociateNode in RecreateSprigs) it...

The fix is only about mouse handles. That is, when you select/de-select/move many components. This is what you asked here, right?

kgiddings

Well I asked about slowness with movement with the mouse and the keyboard (see my first response to your request for a project above).  The slowness of selection of a single component came to light today,  but as you had made changes I wanted to see if this selection issue wasn't a problem that you had already dealt with before raising it,  but as I can't test it yet I thought I'd better raise it now.  BTW if I remove the LMDComponentTree from the interface,  the selection of an object is instant,  so it's definitely with that component that there is a problem.

kgiddings

Any news on the update?  We've finally ditched the object tree - it was a nice to have,  but it slowed everything down too much.  

Regards

Keith

Rascular Technology

Adding my 2pennyworth here....

The latest SVN change for mouse handles makes a *huge* different to performance for functions like dragging multiple items.Thanks!

BUT, there's one bug (so far). If I call the Designer's SelectAll method, the drag handles don't appear. They are selected, but just don't have the handles shown.