> So, somewhere between 0.4.0 and 0.6.3 someone made a bitmap version. And > somewhere after 0.6.3 and the kernel driver it was made the default and the > non-bitmap version was removed. Someone (Alan?) wrote the bitmapped version for the kernel and Ralph merged it back into bttv 0.6.x (and probably added the comment about it being slow). As I started porting bttv to the new i2c layer and maintaining the 0.7.x versions one of the first actions was to kill one of the two clipping code versions. I decided to go with the bitmapped version because the code was robust and easy to understand. As the clipping usually does'nt change that often performance is'nt that critical IMHO. Also the bitmapped clipping code is much faster in current versions than in 0.6.x. > As Alex Bakaev said, there is no need for the risc buffers to be contiguous. > The kernel could allocate a small 4k buffer for each field's program. If the > buffer fills up, allocate another 4k and chain the program from the first > buffer to the next with a JUMP instruction. Maybe I do it this way some day. I plan to rewrite the risc code generation and capture handling completely. There is alot of historical cruft in the driver which predates the v4l API. Also the kernel has much better support for PCI DMA these days (see kiobufs + dma-to-userspace, see Documentation/DMA-mapping.txt, have a look at btaudio.c). I think the ugly memory handling code can be killed now. Gerd -- Protecting the children is a good way to get a lot of adults who cant stand up for themselves. -- seen in some sig on /.
