I can see how it would be useful, but as a software author, I would prefer we didn't go down that road. In order for it to be useful, we'd probably want to use a standard vector format, and most likely that means SVG. Unfortunately, supporting SVG textures requires tools to incorporate some 3rd-party SVG library. Realistically, this would be the case for any standard vector file format; they're just too complicated to expect an LDraw program to directly parse them. (Using the LDraw format itself as the format for the vector "textures" would seem to defeat the purpose, since that wouldn't make part creation any easier.) From my point of view, that's yet another library that I have to get working in LDView, and I already have enough that it's quite difficult to get LDView to build on a clean machine. Adding one more just complicates things further. Also, it takes a lot longer to load (and then render) an SVG than to load a PNG.
In order to get the performance gains that textures bring, the vector texture would then need to be converted to an image by the rendering program, and that image would then be used as a texture map. And while it's true that the program could generate the image at a resolution that is based on the size at which the image is projected, I don't think this buys us much over simply making the PNG texture big enough to be useful in the largest part using the pattern.
I do feel that it would be perfectly reasonable to include vector versions of the textures in the parts library, and make it optional for rendering programs to use them. However, I feel that any such vector "texture" should be required to also include a PNG version that is simply a rendering of the SVG at an appropriate resolution. This would make it so that if someone created a part using a texture, and someone came back later and needed the texture to be bigger, they could simply re-render the vector graphic into a higher-resolution PNG file, and both the old and the new file would then work fine.
In order to get the performance gains that textures bring, the vector texture would then need to be converted to an image by the rendering program, and that image would then be used as a texture map. And while it's true that the program could generate the image at a resolution that is based on the size at which the image is projected, I don't think this buys us much over simply making the PNG texture big enough to be useful in the largest part using the pattern.
I do feel that it would be perfectly reasonable to include vector versions of the textures in the parts library, and make it optional for rendering programs to use them. However, I feel that any such vector "texture" should be required to also include a PNG version that is simply a rendering of the SVG at an appropriate resolution. This would make it so that if someone created a part using a texture, and someone came back later and needed the texture to be bigger, they could simply re-render the vector graphic into a higher-resolution PNG file, and both the old and the new file would then work fine.