[Lazarus] Raster image data in RGB24 or ARGB32

[petr.kristan at epos.cz]

Martin schrieb:

>> 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.
> 2) The IDE only opening a tab, and defer creating the SynEdit. I haven't 
> looked into this.

With multiple editor windows, the files must be kept (and parsed...) in 
their own pool, separate from the SynEdit viewers.

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

Even if newer machines have enough power to process a huge number of 
files within a few seconds, I'd take care for users with old equipment - 
who else would do, if not Lazarus? Virtual machines also can have less 
RAM, and performance can become very poor once such a system starts 
swapping.


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

When the user has not seen an file already, it doesn't matter whether it 
was modified on disk. Whenever a modified file becomes active in the 
editor, the user should be asked whether the file should be reloaded, so 
that parsing of inactive files may be a waste of resources.


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

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 get's on the todo list now (but little priority). Maybe creating just 
> one merged list, and then simply clear+copy for each synedit.

That's a wrong approach, IMO.

DoDi