On Thu, Nov 11, 1999 at 12:56:58PM +0100, "Ewald R. de Wit" <ewald@xxxxxxxxx> wrote:
> Well the algorithm involved is a simple 256 byte lookup table (or 3 of
> them for each of the RGB channels). There is not much one can screw up
> about it, both performance and precision wise.
The only different to the gimp is that it is signal driven, i.e. the work
is done in the gtk idle loop and the screen is updated as necessary. Maybe
the cycles are burnt here.
Yes... anybody who wants to do a profile? ;()
> I consider any image that doesn't fit into RAM to be a pathological
> case and I don't really care about this sort of oddball performance.
Magazine covers rarely if ever fit into memory (unless you give up on
undo).
> image as a large file into memory. Chances are that the linear layout
> of this large file give a much more efficient disk access pattern then
> the Gimp's current swap file.
In the case of brightness_contrast and similar operations, the layout is of
no consequence to performance (the pixels are not connected and can be
processed in any order).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
