Is there any intention for adding support for texture compression?

[two-tone-]

I thought of putting this in Feature Requests but decided against it because while I do want this I'm just wanting to generate discussion around the topic.

Examples of texture compression algorithms are S3TC, ETC, and the newer ASTC.

[Laurent]

Nop.

But you can explain why you would need it, it can help the feature to be considered in the future

[FRex]

S3TC is also patent encumbered.

[two-tone-]

Only if you're trying to write software that decodes it.  Telling the GPU driver to decode it is not a violation of those patents.

I just like having the option.

[FRex]

But because of patent it doesn't come in some Linux distros by default. In Fedora I had to install the extension for GL myself, in OpenSUSE it doesn't come by default too I think, it used to not come with Ubuntu, now it does (I think). I think that extension is technically illegal under USA law but no patent holder would go after pebbles from suing singular users.
Most of us are not from United States of Patents so for 'us' personally it doesn't matter, especially Laurent is in France (I presume) and look what clusterf**k of patent and DRM breaking software VLC and libdvdcss are - and it's all legal under French law.

Also it'd really really screw what SFML does now, now everything can be loaded in such way : Texture <-> Image <-> File.
GPU only would break that chain. It'd also get into the way of file loading/decoding, SFML uses stbi for loading and writing everything right now, so code for detecting if that's s3tc file and loading it would have to be stuffed near/around stbi calling code that is now in place.

It's really much headache and work for little gain. I'd much rather see the APIs be less airtight so you could use own texture you loaded with GL code in sf::Texture instance and then everyone could do what they want for loading and all.
SFML to me seems hardly about 'options'. I mean, we don't even get anything except RGBA8 for color channel choice.

Either way last word on everything is up to Laurent.

Also, what about the other two algorithms?

[two-tone-]

But because of patent it doesn't come in some Linux distros by default. In Fedora I had to install the extension for GL myself, in OpenSUSE it doesn't come by default too I think, it used to not come with Ubuntu, now it does (I think). I think that extension is technically illegal under USA law but no patent holder would go after pebbles from suing singular users.
Most of us are not from United States of Patents so for 'us' personally it doesn't matter, especially Laurent is in France (I presume) and look at what clusterf**k of patent breaking software is VLC under French law.

It's reliant on proprietary drives, yes.  But so what?  Shouldn't the game dev decide if they want to use it and not us?

Anywho, I just thought of a good reason to have it.  I like the simplicity of creating an in-game interface with SFML. I could easily see people using it to create interfaces in 3D games.  The issue is that in 3D games the devs and artists have to be very careful with their memory budget, which is why they use compressed textures.  You can't do that with SFML.