A better scheme for a movie player would be to create a single texture and then keep replacing it's contents. Or use two textures and double buffer. But once created these textures would not move in the LRU list unless you started something like a game in another window.
if we supported that in any reasonable fashion (at least on radeon/r200), movie players are very texture upload bound, well at least on my embedded system, I do a lot of animation with movies, and mngs and arrays of pngs, and most of my time is spent in memcpy and texstore_rgba8888, this is a real pain for me, and I'm slowly gathering enough knowledge to do a great big hack for my own internal use,
Perhaps a wild idea ... does APPLE_client_texture do what you want? If so then it might be a lot simpler and more reusable to test/optimize/fixup that then to start from scratch.
That should allow a straight-copy from data you create to memory card the can texture from, which is about as good as possible.
For subimage modification the spec seems to permit modifying the data in place then calling TexSubImage on the subregion with a pointer into
the original data to notify of the change.
Regards,
Owen
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
