On Mon, May 30, 2011 16:59, michael.vancann...@wisa.be wrote: > On Mon, 30 May 2011, Tomas Hajny wrote: >> On Mon, May 30, 2011 16:16, michael.vancann...@wisa.be wrote: >>> >>> Try the following code: >>> >>> Img:=TFPMemoryImage.Create(0,0); >>> Img.UsePalette:=False; >>> Img.loadFromFile(FileList[i]); >>> >>> That should work much faster. The reason is probably that the default >>> image >>> created by the reader uses a palette, which is of course dog slow when >>> reading >>> large images. >> >> Interesting. What is supposed to be a "large image"? I ask because the >> original post mentioned 35 kB and 65 kB (and indirectly also dimensions >> around 600x400 if I understand the program output correctly) which I >> certainly wouldn't consider as "large" (and the mentioned time necessary >> for reading it surely not appropriate regardless of using palette or >> not). >> I guess that some optimization may be reasonable because such pictures >> could be loaded and displayed (including conversion from true colour to >> 256 colours palette) faster even on a 486 machine... > > It depends on the colors used. The default palette algorithm simply > allocates a slot per found color in the jpg and returns the index of the > slow. For a picture, this will create a huge palette, in which the search > for a color is in essence linear, so n^2 lookups. > > So, dog slow. > > You could obviously speed this up by creating a palette yourself, and > limiting the number of colors. > > Or, best for pictures is not to use a palette, which is what my solution > entails.
OK, I see. The point is not about what I need or not (I don't need to work with pictures at the moment) but about what will happen if people start using the current code as it is provided in FCL. I'm sure there are various possibilities for some "optimization" - should it be using a different (faster) algorithm for creating the palette (e.g. different algorithms depending on whether the original picture contains a palette or not), not creating the palette by default for pictures not using it (or not doing it at all unless explicitly requested, i.e. changing the default behaviour as suggested by Matthias), limiting the maximum colour depth for pictures with palette (as mentioned by Ben), etc. In any case, I'm afraid that the current default behaviour will not work well for majority of FPC users and their use cases. Tomas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
