the idea of a non-square bitmap format would be pretty cool though. the idea is that squarness is a totally arbitrary shape which we fill in with pixels, only because its the simplest geometry to use. gpu's with their vecctor capabilities could handle more complex shaped textures without much trouble. a 2d triangle really isnt that complex though, and could easily be derived from a polygon, and could be represented by only 6 floats. once the bounds are established you provide a list of pixels that can fill that triangle (essentially the inverse of what happens when a polygon is rendered), line by line, skipping any pixel slots that are out of the polygon bounds. you can combine multiple triangles filled with pixels in one file format. the format would start with a header with offsets to polygon definitions and pixels, every triangle would have offsets and number of pixels allocated for that triangle.
the pixel data could also be compressed using the same algorithm you would use for dxt. most compressed formats compress 4x4 blocks of pixels, so rather than store single pixels in the pixel areas of the format, you store pixel blocks, essentially squaring the resolution of the format for the same file size.
perhaps such a texture format could be embedded directly into the model format. since pixels in the triangle are stored in the same order they are rendered, the rendering of that triangle can be accelerated further. of course this idea would cause some issues with creating models, for example if you model the object and begin texturing, but decide you want to add more geometry, you may end having to toss pixel data on any polygon that is changed, or some how deform it. of course theese issues could be worked around. also how to deal with materials, normal maps and the like. perhaps with a multichannel pixel format (i for one would like to see compressed texture formats that work well for a larger, possibly dynamic, number of channels).
this setup would do a number of things, the first of which is completely eliminate pixel wastage, freeing up vital graphics memory. the extra vector data needed would most likely be less than what would otherwise go to storing unused pixels. texture bake operations would look better and be more efficient. and most importantly this should fall well within the capability of the existing video hardware (though im not sure if the support is available at the api level).
