On Thu, Nov 04, 1999 at 09:30:56AM +0000, Austin Donnelly <[EMAIL PROTECTED]> wrote:
> Look, you're all missing the point.
No, since we are not talking about the current situation...
> Gimp does it's own tile swapping not because it wants to control the
> layout on disk. As some of you have pointed out, this is futile.
... which is probably why this technique is soo common. "Algorithms" by
John Sedgewick has a nice chapter on why using virtual memory for objects
larger than it is a very bad idea in general (exceptions possible).
> The only reason to swap a tile at a time is to do with controlling how
> far apart in memory neighbouring pixels are.
Which does not mean that the situation on disk cannot be improved? Most
databases actively use spatial indexing _on disk_.
> Consider a very wide image.
(which will not fit into memory)
> memory, there seems little point in converting it into a linear buffer
> before writing it to disk. This would certainly take more time than
> it would to just hand the data to the OS.
certainly... but the current situation does a very suboptimal layout on
disk, which could be improved (in some distant future version ;)
> And gentlemen, this is not rocket science. It's what undergraduates
> are normally taught in their basic "OS Functions" lectures. The gimp
> is a good example of why application-specific paging control can be a
> performance boost. Now can we drop this silly subject, please?
If it's so basic, why do you describe it as silly, and why should we NOT
talk about implementing it in gimp?
I rather think _you_ are missing the point (which is disk layout and
minimizing seeks, and _not_ a better memory layout. The tile based scheme
leads itself naturally to spatial indexing, in fatc it's already half the
way to go).
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |