[Lazarus] RFC: remove StayOnTop for splash screen

[Mattias Gaertner]

On Wed, 03 Mar 2010 04:28:41 +0100
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

>[...]
> > AFAIK I'm the only one that has provided some profiler output and it
> > showed that the synedit scanner is not a big number. The bigger
> > limitation is the visual controls (pagecontrol, pages).
> 
> In a simple approach the controls should not have any impact on the
> performance. Since the tab clients are all of the same type (SynEdit), a
>   single (visible) client control and a separate tab control would be
> sufficient. When multiple SynEdits are required, all but the active one
> can be hidden (see my notebook-docking approach).

Hmm, this could save some time. I never compared tabcontrol with
synedits and pagecontrol with synedits. Can you create a test app and
time the results? Then we know, if it is worth the effort.

 
> >>> Then again. My PC is about 3 years old, with an average of 10 - 20 
> >>> SynEdits, it takes 1 to 2 seconds of parsing. Opening a 100 files on 
> >>> loading of the IDE may be a legitimate action, and may have good 
> >>> reasons, and certainly can be justified by personal choise => but how 
> >>> many people are affected by it?
> >> That depends on the meaning of "open". The filenames can be imported 
> >> from a project or desktop layout file, into the file pool. Actual 
> >> loading can be deferred until the files really are required in the IDE.
> > 
> > "Open" is here: in the source editor.
> > Of course the IDE handles hundreds or thousands of files in the
> > background.
> 
> What's the difference?

1. some minors like the IDE warns if it is not a text file. 
2. forms are loaded if the options are enabled
3. a synedit is created
4. a page is created

The last point is what Martin and me don't understand. Why not close
files? Who needs this optimization?

 
>[...]
> > They are parsed only once and only because the user wanted the file to
> > be open in the source editor. I still see no reason why someone wants
> > to always open a hundred files in the source editor.
> 
> Me2, but I frequently found 30+ open files when exploring the Lazarus
> project. When the tabs are not closed manually, they will be reopened at
> the next start.

30 files costs a second. Big deal.
The optimization is needed when you open a hundred files on a slow
system. Who needs this?

 
> >> I just don't understand what you mean. The SynEdits should *perform* 
> >> edit commands, but the *detection* of keycodes is the job of the 
> >> framework (IDE).
> > 
> > It does for other commands. And since synedit already can handle
> > keys on its own, the IDE just tells synedit which key code should do
> > what.
> 
> That's not in accordance with MDI nor MVC. You oberserved the overhead
> yourself, that results from a deviation from accepted designs.

The overhead is (or was) a one time initialization function that
costed for 100 files 0.15 seconds. That's why it was not optimized. 


Mattias