[Lazarus] RFC: remove StayOnTop for splash screen

[Mattias Gaertner]

On Mon, 01 Mar 2010 22:48:12 +0000
Martin <lazarus at mfriebe.de> wrote:

> On 01/03/2010 21:12, Hans-Peter Diettrich wrote:
> > Flávio Etrusco schrieb:
> >
> >> Guess I'll have to do some work in SynEdit then. It used to be my area
> >> of expertise after all ;) But the code in Lazarus is a (almost)
> >> completely different beast, and maybe not much can be done with
> >> codefolding wihout making some concessions...
> >
> > IMO the IDE should use an cache for the SynEdits, that must contain at 
> > least the currently active text file. More opened files can be parsed 
> > and added to the cache later, when they are really activated. When the 
> > systems runs out of memory, old entries can be removed from the cache. 
> > Inactive files can be parsed in the background, when the system is idle.
> 
> Well there are 2 option. Actually both can exist at the same time.
> 
> 1) SynEdit scanning on idle. I had that idea for a long time already, 
> but a lot more needs to change in SynEdit, before this can be done.

I just opened 219 files, which took 6 seconds. The synedit scan
takes less than a second. Half the time was spent in gtk/X
handling the tabs.
I think there is no need for an idle scan.


> 2) The IDE only opening a tab, and defer creating the SynEdit. I haven't 
> looked into this.

Yes, that could save a second. wow. ;)


> 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?

I don't see how people can navigate a hundred files. Lazarus
has only shortcuts for the first ten. And for the window menu you need
a big screen with a tiny font.

 
> Caching, and removing? why re-invent the wheel. It has a similar effect 
> than the OS doing swaping memory to swap-file...; And you have to keep a 
> copy of all open files, just in case they get modified on disk, while 
> they are in memory.
> 
> Also having looked at the gprof numbers, the time seems to be lost while 
> assigning the keycodes. Which seems to be done in a very inefficent 
> manner. My guess is that the IDE-defaults/user-configs are merged with 
> the SynEdit defaults, and during this probably each code is tested for 
> existence (looked up) first, before potentially being added. Given that 
> there are 100of key combos, which have to be iteraded a 100 times (and 
> this is for each synedit...) => well (rather not so well).
>
> It get's on the todo list now (but little priority). Maybe creating just 
> one merged list, and then simply clear+copy for each synedit.

I did that. Now it does not appear in gprof any more. Saves a few
percents. I doubt someone will notice.


Mattias