Sottek, Matthew J ([EMAIL PROTECTED]): > > Such a capability needs to be in the client side, since different > > applications have different needs regarding the accuracy of the > > Y'CbCr->RGB conversion for optimization. So, really here we just > > need a method where Xv can tell a client 'I only support one overlay > > at a time'. > > Then make the interface smarter. Pass a flag to force a fail when the > software would be needed. 90% of the apps will just want consistent > behavior and won't want to full with fallback code. Forcing the > client to implement alternate rendering methods is just going to make > for a lot of mostly broken clients that work for some people some of > the time (i.e. what we have now), if the client is smart enough to > have another "better" software renderer then they should be smart > enough to pass another flag.
Abstractions like SDL are reasonable and support Xv with software fallbacks, and SDL gets released more often than X (useful for bugfixes). Applications which are more specific can make intelligent decisions about how to handle the loss of hardware scaling. In xine for example, they have coded specific scaling routines for 4:3->16:9 scaling (assuming square pixel of course). Personally, I'd like to see as little intelligence as possible in X, but I do admit that it is unfortunate so many apps which currently use Xv just do it directly. Still, I really wouldn't want to have my X server wasting its time doing scaling. Ugh. It's way too expensive to have a software fallback. -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
