"Nemosoft Unv." wrote: > On 31-May-01 Ben Bridgwater wrote: > > 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... 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. > > 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. I guess I *could* delete the "static" ;-) If you're thinking of converter chains, then better just to guarantee converters to/from a couple of intermendiate formats such as RGB24 or I420. > > 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 :)) 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. > NB: what does GetConvertor() do when you don´t have a convertor for a > desired combination? It just returns a NULL pointer? Yep. The other alternative (which I havn't had the need for) would be to write 3 or 4 totally generic, presumably slow, converters to fill the gaps. > > 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. There's some out there. In think SAMPEG-2 and/or DVDView has some VIS code, and the VideoLAN DVD viewer has some Altivec. For Solaris there's Sun's media lib library which is VIS optimized. > 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. Will do. Ben
