True as far as it goes. An OS will manage virtual memory, swapping data between RAM and Disc as needed, normally in pages of some fixed size.
However, if the application is "naive", some worst case behaviour can emerge. Imagine an application that routinely access the first byte of a page, and then accessed the first byte of every other page before re-accessing the first byte of the first page again. The application is not addressing many BYTES, but it will thrash the virtual memory badly. A typical image rotate will have this behaviour on either source of destination. What you're aiming for is locality of accesses, where multiple accesses all fall within a page. For raster graphics this can be achieved by accessing data in a tiled way, so that adjacent pixels in both X and Y are "near". This can be done WITHOUT a tiled virtual memory system, you just need to access the data in a tiled order. This can be done by finding the pseudo-tile T a (x,y) coord is in (simple divide X, Y by the the tile size), calculate the tile base address of the tile T (T * tile_bytes) and then work out the offset of the data from the tile base (x and y modulo tile side, then multiply the new Y by tile side). I has a fancy 2D Object browser on SunOs that was thrashing, and by simply implementing "address_of_object()" as outlined above, the memory behaviour was immaculate. BugBear -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAD1remYX3b4giejGN2R-zKGfy9T1EXbtDJiwBHU8KvmCWuP8HA%40mail.gmail.com.
