>> It's definitely not a stupid question. I don't know if I fully >> understand what you're asking for, but it sounds like it would be a >> useful feature. Let's discuss it, but keep in mind that anything and >> everything is subject to "have to do it later" due to constraints on >> the project. > > I would not postpone it. This is _the_feature_needed_for_video_playback_. > If there is no way to "upload" an image into off-screen video mem > and scale&colour-key it over an area on-screen, any video app will > be slow as hell.
If the texture unit can read from system memory and can read video format pixels then that would be ideal. Uploading the video image to local memory first should not be necessary (it is for overlay, but this in general only allows playback of a single video stream), but could be an option too. Being able to read huge textures from system memory would be a nice feature anyway. > Note that this includes anisotropic scaling (right word ?), ie > x and y scaling factors being different. I don't think anisotropic filtering will be needed. The scaling factors may not be identical, but the same filter (bilinear) can be used for both. I don't think there's much choice for the filter besides nearest and linear... --ms _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
