Use of blob responseType in ImageLoader.
See original GitHub issueDescription of the problem
The ImageLoader sets the response type of XHRLoader to blob. This causes a problem with Chrome (53.0.2785.116 m) and running the script from the local filesystem, while fetching textures from a web server. It seems to me that this is a security consideration of Chrome. The closest info I found is this, but that does not seem exactly about that. In Firefox (49.0.1) there is no issue.
For me this functionality is important, because I’m using Three.js to teach CG and the students should not worry about web servers. Also I’d guess there are people, who want to prototype some things with Three.js and not set up a web server to do that.
I made the responseType to be a parameter of the ImageLoader (and the TextureLoader) and with arraybuffer type there is no problem: see image.
The top row uses the r80 implementation with blob and the bottom row uses arraybuffer response type. With the arraybuffer I base64 encode it and set it as a data URL to the image.
You can also see that actually the arraybuffer seems a lot faster then the blob implementation. This seems to be that for some reason Chrome knows how to cache the former, but not the latter.
If the script is in a web server: see image.
With no caching the arraybuffer seems marginally faster with the texture I used: see image.
Live example (download the file, the modified lib and open it from the local filesystem to see errors): http://tume-maailm.pri.ee/ylikool/ComputerGraphics-2015/other/uv-test/index-loadingTest.html The no-cache version: http://tume-maailm.pri.ee/ylikool/ComputerGraphics-2015/other/uv-test/index-loadingTest-noCache.html
I did this with r80, but r81 seems to have the same issue.
Should I create a fork and PR with the responseType as a configurable value of the TextureLoader and ImageLoader?
Might also be related to #9824, as, like I noticed, the request with blob response type does not cache the response in Chrome. So it will send new requests until the first one gets back and Three.js’ own cache kicks in (maybe?).
Three.js version
- Dev
- r81
- r80
Browser
- All of them
- Chrome
- Firefox
- Internet Explorer
OS
- All of them
- Windows
- Linux
- Android
- IOS
Hardware Requirements (graphics card, VR Device, …)
No special requirements.
Issue Analytics
- State:
- Created 7 years ago
- Comments:11 (11 by maintainers)

Top Related StackOverflow Question
Firing up a local web server is trivial: https://gist.github.com/willurd/5720255
#10439