[libdc1394-devel] Let's get rid of extra buffering

[Johann S. <j.s...@ir...>]

I thought that subject line would catch your eye. :-)

Seriously, who uses extra buffering (and its do_extra_buffering flag)? 
  Perhaps someone can justify its existence, but I only see problems 
with it:

  1. It is slow (does a bunch of memcpy's).
  2. It is unpredictable (you never know when it will trigger an 
unexpected block of processing time).
  3. It does the opposite of what one might expect (slows down average 
throughput instead of speeding it up).
  4. It loses the filltimes of the extra buffered frames (a problem 
that will require a kludge to fix with backward compatibility).
  5. It causes a segmentation fault if the user asserts it after the 
set-up function (admittedly easy to fix).
  6. It unnecessarily complicates the frame capture interface (bad 
enough that we have a drop_frames state in there already).
  7. It does not solve any problem that can't be solved by setting a 
larger number of DMA buffers to start with (it does not return to the 
DMA buffers anyway until after the user has disposed of all the extra 
buffers).

I can't think of a single reason for keeping it (apart from backward 
compatibility, but then this is still beta code).

I propose that we make the capture interface simpler, faster, easier 
to understand and easier to maintain by getting rid of extra buffering 
before releasing version 1.0.

What do you think?

Johann

-- 
Johann Schoonees                         Imaging & Sensing Team
Industrial Research Limited, PO Box 2225, Auckland, New Zealand
Phone +64 9 9203679 Fax +64 9 3028106 http://www.is.irl.cri.nz/
Camwire's home:  http://kauri.auck.irl.cri.nz/~johanns/camwire/