On 31-May-01 Alan Cox wrote: >> In case youre interested... Ive written up my idea on how an (expandable) >> shared library should look like. The URL is >> http://www.smcc.demon.nl/ccvt/ >> This is a draft, not fully completed yet, and open for debate. It >> contains >> documentation from both the programmers point of view (us!), and the >> library maintainers/writers (ehm, us? :)) POV. > > Would it be a performance win in some cases to be able to > > x=f->open(h,w) // CVT_SIZE_UNKNOWN for unknown > x->function(...) > .. > > f->close(x) > > So that the library can build optimised tables or hand back functions > optimised for known sizes (CIF, QCIF, multiple of 16 pixel wide etc) ? Hmm; I think there´s hardly any gain there... Conversion is a rather straightforward process with little parametrization. I´d rather fix the width to multiple of 4 pixels and opmizize with that in mind (think about certain YUV formats that have only one color component per 4 pixels); so far, nobody objected to that :) I would like to keep the amount of data kept outside of the functions to a minimum, preferably 0. It would make multi-threaded design easier (using only stack variables), plus you don´t have to create a structure (call it a poor-man´s class) for every instance of the function that you need to hold the extra data. - Nemosoft ----------------------------------------------------------------------------- Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft >> Never mind the daylight <<
