Re: Conversion library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



"Nemosoft Unv." wrote:
> 
> On 01-Jun-01 Ben Bridgwater wrote:
> > "Nemosoft Unv." wrote:
> >
> >> On 31-May-01 Ben Bridgwater wrote:
> > Not really - just add flags to indicate what processor attributes (MMX
> > etc) each converter needs, order the accelerated converters before the
> > others, then scan the list for the first matching one suported by the
> > actual processor attributes.
> >
> > I'm open to suggestion.
> 
> I would simply replace the function pointer with the most optimized
> function during initialization; that way the logic in GetConvertor can be
> kept really simple (otherwise, you´d end up with a different GetConvertor on
> each platform!).

I don't see that. For example, If some converters are flagged as
requiring MMX, and a non-x86 CPU is detected by whatever means
(conditional compilation and/or /proc/cpuinfo), then the MMX processor
attribute would be set false and those converters would never match. Of
course we may or may not regardless have to do ./configure (not yet
supported!) based conditional compilation if gcc fails on assember that
doesn't match -mcpu/arch (I don't know what the behaviour is).

Let me see if I can get this out this weekend in it's current form, then
we'll have something more concrete to discuss.

> > For these formats "to" is useful for X display, and "from" is useful for
> > V4L and AVI. You're right that's the way it's implemented - as a bunch
> > of individual converters that cover the common XImage formats, but the
> > point is that the app can just do a dumb "descriptor.format = PackedRGB,
> > descriptor.r/g/b masks = XImage.r/g/b masks", then ask for a converter
> > to/from that format.
> 
> So you have a ´general purpose´ convertor that can convert to almost
> anything (at the price of being slow, presumably)?

More importantly you have an application API that supports general
purpose image descriptors, and whether a particular conversion is
available is then just a library implementation issue. The application
isn't forced to consider individual formats unless it actually wants to.
Adding a fallback "general purpose" converter is simple - I'll add one
before I release it.

Ben





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux