Re: [AD] WIP compressed texture support patch

[SiegeLordEx <slabode@xxxxxxxxxx>]

On 12/09/2014 02:33 PM, Trent Gamblin wrote:
> I'm not very familiar with compressed textures, but are block width and
> block size standard sort of things in this domain? For example would PVR
> compressed textures be able to use al_get_pixel_block_*? If they're specific
> to DDS, does it make sense to have such generic names for them?

I looked at the PVRTC format just now, and it seems like it also 
subdivided into blocks (although it works very differently than these 
DXT formats).

> What is al_pixel_format_is_video_only? Could this be the same thing as
> al_pixel_format_is_compressed? When would it differ?

There was no big idea behind this, I just thought that perhaps one day 
there could be other (non-compressed formats) that don't have memory 
bitmap implementation (e.g. some fancy YUV? formats?). It's not a 
critical part of this feature.

> Does the OpenGL flipping thing in any way potentially cause patent issues? I
> notice it's almost decoding and re-encoding rows, but I'm no expert.

Yeah, I am a little worried about that. The code is not doing any 
compression/decompression, but merely taking advantage of the memory 
layout of the blocks. Some of these layouts are the same as those used 
by formats which are not patent encumbered (e.g. consider RGTC which 
uses the same format as the alpha block of DXT5). Mesa implements RGTC, 
so it must be fine by them.

Obviously it's something only a lawyer can answer... (although I could 
inquire about this with some knowledgeable people). What I could do is 
add a compile time flag to disable this. This would only affect the 
blocked locking feature for these formats, and leave the on-the-fly 
compression unaffected. Other formats don't seem as patent encumbered, 
so a user that does not opt into this block flipping for the DXT formats 
can still use other formats.

-SL