Failed loading texture file

[oskycar]

#iChannel0 "file://tmp/1.png"
#iChannel1 "file://tmp/2.png"

on macos 10.15.2 in vscode 1.42.1 , I got such error:

" Failed loading texture file vscode-resource:/tmp/2.png"

I had tried other image format ,such as 1.jpg . but got the same error;

[Malacath-92]

Excuse my absence for the past week.

I assume something is wrong with path resolution on MacOS, however if the extension fails locating a texture it should certainly give some more information about it, which if I understand you correctly it doesn't. I'll investigate that.

However, I have no way of testing MacOS. So unless you want to try debugging the extension yourself @oskycar I can't help you.

[stevensona]

Just seeing this now. I will try to reproduce tomorrow.

[stevensona]

I am unable to reproduce this. @oskycar in VS Code, are you opening the directory containing your GLSL program? The extension uses the workspace path to load files, which is set by opening a "directory".

[Malacath-92]

@stevensona: files relative to a shader are also supported when not opening a folder/workspace. If that does not work, then it is a bug. I'll make sure tomorrow tha6 this is not broken on other platforms. Though if it is, it looks at least like a temporary workaround would be to open a workspace.

[Malacath-92]

@stevensona @oskycar Did either of you test this again? Files relative to the shader work for me on Windows, but it's still very much possible that they don't work on MacOS.

[oskycar]

@stevensona @oskycar Did either of you test this again? Files relative to the shader work for me on Windows, but it's still very much possible that they don't work on MacOS.

It did work on MacOS, when use relative path.

[Malacath-92]

So if it works, we can close this issue then?

[oskycar]

so, does it meas that we cann't use absolute path on MacOS platform?
though I can open the file by cmd+click the url.
we should add mentions in readme file.

[Malacath-92]

Huh, I might have misunderstood something here. Is your initial problem not with relative paths? Absolute paths should absolutely be supported, in fact they are given the highest priority out of the three possible ways to resolve a file path:

1. Check if file is found assuming user gave an absolute path,
2. check if file is found assuming user gave a path relative to the source file,
3. check if file is found assuming user gave a path relative to any open folder.

So to clarify, if any of those three should succeed but doesn't, then that's a bug.

[stevensona]

@oskycar the path file://tmp/1.png looks like a relative path. Maybe try like so file:///tmp/1.png if there is a image at /tmp/1.png.

[oskycar]

@oskycar the path file://tmp/1.png looks like a relative path. Maybe try like so file:///tmp/1.png if there is a image at /tmp/1.png.

yes, I also try it like that file:///tmp/1.png, and I'm sure I had copyed file to the tmp path;

today, I tried in many ways ,the bug is like this:
`
when my project path is at "/Users/xxx/project/shadertoy" ，it looks like shadertoy in vscode can only open file in this directory and subdirectories.

#iChannel0 "file:///tmp/1.jpg" open failed
#iChannel0 "file:///Users/xxx/Desktop/1.jpg" open failed
#iChannel0 "file:///Users/xxx/project/shadertoy/1.jpg" open success
#iChannel0 "file:///Users/xxx/project/shadertoy/subdir/1.jpg" open success
#iChannel0 "1.jpg" open success

I'm sure I had copyed file to such directory;
`

==========================================================

I had encounter another strange problem，when I comment the iChannel0 code，but it looks that shadertoy still read such files and may got prompt. for example:

//#iChannel0 "file:///tmp/1.jpg"
// #iChannel1 "file:///Users/xxx/Desktop/1.jpg"
I still got error message about failed open such files in vscode when run the code .

[oskycar]

MacOS 10.15.2
VSCode 1.43.0
Shader Toy 0.10.2

[Malacath-92]

Thanks for the detailed report @oskycar :)
I can reproduce this, embarrassingly I never tested a scenario as you did when adding the absolute path feature. The issue here is that vscode is very strict with the rules of loading resources, hence the path that you see in the error starts with vscode-resource:/. It indicates to me that vscode found a file at that path, passed it to the Webview (the GLSL Preview) but that then didn't have access to the resource.
I'll take a closer look at how to give it access in such a case.

[Malacath-92]

#88 should fix this