AndrewB

I noted several inaccuracies in this thread including the one quoted here and wanted to clear them up.... First of all to characterize SNAP as bloated is a gross misrepresentation no matter how you slice it. If you look at the downloadable file on the SciTech website you will see that the package itself is no more than 11.5mb for our largest package - the package contains support for hundreds of chip sets (more than 250). A single accelerated chipset diver can still be delivered via floppy disk. If you look at memory foot print here again SNAP has proven to be amazingly small - though tough to accurately gauge memory usage of a driver from home, I would be amazed if anyone could find a windows driver that has a smaller memory footprint then SNAP, while still offering acceleration DDC, plug-n-play..... (Read not a DFB driver) . In terms of acceleration our win9x driver for the i945 matched up very well to the OEM driver and in many real world examples was significantly faster. Where we did experience some bloat was in our optional GUI based control center (based on wxHTML) if memory serves this component required a minimum of 5mb of memory when idle , and required another 5mb when in use (not exactly what we had hoped for when we built it) SNAP drivers themselves are today running on embedded systems with less than 32mb of total sys memory available (in some DOS cases far less memory) and still offering very "SNAPy" 2D accelerated performance! Infact in one PPC Linux example a SNAP driver for an ATI graphics chip is providing full 2D video acceleration (HW motion comp and scaling) on a PPC chip clocked at less then 350mghz with no floating point processor, 64mb of sys memory and if memory serves 32mb of graphics memory - not a lot of room for bloat here.