A question for the much more experienced fx people on here, is there any disadvantage to using thin rectangular textures as opposed to square textures?
Ex: you are using a gradient texture to mask something out, or a series of horizontal lines to simulate static. If these textures just wrap around on their X, is there any reason I shouldn’t make it four pixels, or even one pixel wide?
Depends on their expected use case and target hardware.
Non square textures will not be able to use mipmaps at all on some older hardware, or the mipmapping might look funny. This is limited to older mobile hardware mainly, or you’re still rockin’ a Nvidia GeForce 2 GTS.
There’s also the “issue” that 1 pixel wide textures cannot be compressed. The minimum dimensions of most compressed texture formats is 4x4 pixels, and some formats don’t even support anything but square (like PVRTC). But this isn’t actually a problem since GPU compression is generally somewhere around a 4:1 ratio, so a 1 pixel wide uncompressed RGBA will often be the same memory or less than a 4 pixel wide compressed texture. Some format get a better compression ratio than that, like ETC, but if you’re okay with what ETC will do to your texture you can probably get away with using a 16 bit (RGB565 or RGB4444) format and get even smaller (if you’re using mip maps, since ETC can’t do <4x4 pixels even the “1x1” mip is stored as a 4x4 block).
As a warning ASTC will let you use a 1 pixel dimension as it supports non power of 2 / multiple of 4 texture dimensions, but internally it’ll still be compressed with 4x4 blocks since the compression format can’t get any smaller, as such a 1x4 and 4x4 texture using ASTC use the same amount of memory.
TLDR; No.
Thanks a lot for the info! I really appreciate it
Ben, if you put a TLDR at the bottom of your post, it doesn’t fulfill it’s function! 
Ha ha, just kidding 
Thanks for taking the time to write such an indepth respons! 
is this a fair opportunity to pack multiple into a square texture as-if it’s an atlas?
On ETC1 support we did this as RGBA32 - at 128x128 uncompressed worked well because there’s no artifacts/superior smoothness.
8 lines along the wrap axis was needed to suppress mip issues; I asked for the image to only use 2 mip levels but that wasn’t deemed ‘worth it’ to support (mainly because of how widespread the image was sampled AFAIK or it could have been device hardware thing)