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 <<
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
