…es at the end.
Ubuntu 9.04 couldn't find the dependencies of image2qtree archives. So putting them up first made everything work.
Multi_get is defined in IndexPage.h but was previously never implemented. This gives an implementation.
This means that QT_ARBITRARY_MODULES will need to apply their own prefix of Qt. It also means that if the user needs to add per module library link flags, they'll have to do it themselves with the PKG_ARBITRARY_QT_LIBS option. The previous form of QT_ARBITRARY was not OSX safe since it always applied -lQt<MODULE> for every module, even when the user specified a framework to be linked againsted.
Usually a person uses DiskImageView to insert into the plate. That device will max out the cache. Our mipmapping section doesn't use the cache object so it never deletes DIV cache objects. This means we're at least doubling our memory requirement. This is a dis-tasteful hack where I resize the cache to near zero to clear it. Then mipmapping can do its own thing.
Using exit(0) or exit(1) is generally a bad idea as it doesn't call destructors for local objects. In the case of exit(1), I replaced those with vw_throw() so that users can potentially handle things their own way. Exit(0) were just changed out with return 0. This is so platefiles have a chance to flush buffers and the like. I also made sure all executables end with a defined return value.
Our logging via VW_OUT is truly lazy. Don't put critical functions like loop increment inside the log as it won't happend unless the user kicks on logging.
This is speed up compile times and reduce a single process's memory requirements when using gcc4.2. Previously image2qtree's gcc call would try to use 1.7G of RAM. Now each thread will only attempt to use no more than 600M.
This is speed up perceived compile time and to reduce instantaneous memory usage. The thread to compile geoblend uses about 1.6G by itself in gcc4.2. Now that it has been split down, no single thread uses over 700 MB. I'm using archives only because it is the only way in automake to compile the same source many times with different CPP flags. Geoblend_help.cc is the source for each archive, it just takes a macro to define which version it is instantiating. The downsides of this method is that more hard drive space is used (an additional 40MB) and the Makefile.am looks a little ugly.
It's best to prerasterize any access to the inputs. All single pixel access to a DiskImageResource is mutex'd all to heck. The only downside is the prerasterization to the right mask. There is a possibility that we might be rasterizing a large chunk of an image.
The problem was that we stopped on the first opaque image that files the entire tile. However inorder to get newest TID on top, we insert low TIDs first and then high TIDs last. This meant that if a low TID filled an entire tile, the newer TIDs would never be written. This commit fixes the above problem and also keeps the opaque check optimization in place. We know insert from top down and do a composite every time a new tile is added. Then that composite is checked to see if it is opaque. This is good as it means we might stop faster than the previous code. There's also a small improvement of never calling composite in the event that there is only one input tile.
The cool thing about this Callback is that it does nothing and doesn't use any mutexes. This is an important speed improvement for VW as a lot of our functions like for_each_pixel take a ProgressCallback. When the user gives that a TerminalProgressCallback that adds a mutex deep inside a for loop. Yet if they don't provide anything, the default constructor provides a DummyInstance that unfortunately was previously mutexed. The old dummy instance still updated a progress that was never queried. This commit make the dummy instance request return a NullProgress callback that is not mutex'd in anyway. This is a big deal because this removes a lot of mutexs from a lot of loops.
This actually fixes a frational pixel problem in the resizing code.
ImageViewBase is just a vessel to make sure that what we recieved is actually an ImageView.