Hi,
On 31-May-01 Ben Bridgwater wrote:
> It's just a static list right now. If you're thinking in terms of
> dynamically
> adding MMX converters only if the processor support them,
*nod*
> then another way
> would be just to always add them to the list and put the smarts in the
> GetConverter() - return you an MMX/whatever accelerated converter if one
> exists and the machine supports it, else the default one (if it exists -
> most do).
That´s why my proposal uses function pointers; easier to switch, just once
during initialization. You´d have to build a lot of logic into
GetConvertor...
>> - can you query all available convertors?
>
> There's no reason the application couldn't search the list of converters,
> but I've never had the need.
It doesn´t hurt to be prepared for any future changes ;) I agree that
usually you just want to convert straight from A to B, but in case a
particular combination is not available, a program might want to search for
alternatives.
> Bear in mind that the image descriptors can be built
> dynamically (e.g. to match an XImage matching your display), so it's easy
> for
> example to ask for a converter that'll convert from a V4L format to your
> display format. - you don't have to search for it.
To me, an XImage layout would just be another format in the list... Usually
only on the ´To´ side. The number is limited anyway: 555packed, 565packe,
rgb24 and rgb32, that´s about (and the latter two are already standard :))
> See above - I'd tend just to add them to the list and put the processor
> detection and smart selection into the GetConverter() routine. Bear in
> mind
> that I don't have any MMX converters right now, although of course there
> are
> many around (e.g. from SDL, Hermes, the DVD/AVI players etc) that could be
> added.
*nod* We´ll see.
NB: what does GetConvertor() do when you don´t have a convertor for a
desired combination? It just returns a NULL pointer?
>> I picked the x86 platform because thats where I work on (and program in
>> assembly as well), but is this the only one that has these kind of
>> extensions? Maybe the 68000 CPUs have this?
>
> 68000 doesn't, but PowerPC has Altivec, and SPARC has VIS.
Right; it´s only a matter of time before someone comes up with assembly for
those.
NB: I think the name ´GetConvertor´ is a bit too generic for your library...
I suggest you pick a prefix and use that for all your exported functions.
- 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 <<
