<p dir="auto"><code class="notranslate">ImageLoader</code> and <code class="notranslate">XHRLoader</code> both use a <code class="notranslate">Cache</code> to store loaded assets for reuse, although not very efficiently, at least for some use case.</p>
<p dir="auto">For instance, <code class="notranslate">TextureLoader.onload()</code> creates a new <code class="notranslate">ImageLoader</code> every time the method is called, which means that the image cache is always empty because the image loader instance is only used once. <code class="notranslate">ImageUtils.loadTexture()</code> behaves similarly.</p>
<p dir="auto">My preferred way to solve this would be to put the cache in the <code class="notranslate">LoadingManager</code> (one cache per <code class="notranslate">LoadingManager</code> instance). Each <code class="notranslate">ImageLoader</code> and <code class="notranslate">XHRLoader</code> would share the cache of their parent manager.</p>
<p dir="auto">Users would be responsible to manually purge the manager cache as necessary, to free resources or request updated assets. That could be a problem for an application that cycles through a lot of loaded textures/images, especially if the <code class="notranslate">DefaultLoadingManager</code> is used - users might not be aware of cache implication. Maybe the common cache could be opted-in (<code class="notranslate">loadingManager.useCache = true</code>), which would be equivalent to the status quo. A simple <code class="notranslate">loadingManager.cache.maxSize</code> could be enough, too.</p>
<p dir="auto">Another approach would be to create an <code class="notranslate">ImageLoader</code> instance as a property of <code class="notranslate">TextureLoader</code> in its constructor. The image cache would be reused as long as the same <code class="notranslate">TextureLoader</code> is kept around.</p>
<p dir="auto">I can work on a patch if we agree on the approach.</p>
<p dir="auto">Related to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="16100868" data-permission-text="Title is private" data-url="https://github.com/mrdoob/three.js/issues/3601" data-hovercard-type="issue" data-hovercard-url="/mrdoob/three.js/issues/3601/hovercard" href="https://github.com/mrdoob/three.js/issues/3601">#3601</a></p>
<blockquote>
<p dir="auto"><strong>Is your feature request related to a problem? Please describe.</strong></p>
</blockquote>
<p dir="auto">The application we are building requires camera motion via trackball control, with the direction of movement able to be constrained to the x or y axis.</p>
<blockquote>
<p dir="auto"><strong>Describe the solution you'd like</strong></p>
</blockquote>
<p dir="auto">Currently the TrackballControls example does not provide for this constraint of motion and it would be great if the current example were extended to include this.</p>
<blockquote>
<p dir="auto"><strong>Describe alternatives you've considered</strong></p>
</blockquote>
<p dir="auto">We have implemented this by duplicating/modifying the example in our own repository but consider it may be useful to others as well as a more concise solution if it were included in the example.</p>
<blockquote>
<p dir="auto"><strong>Additional context</strong></p>
</blockquote>
<p dir="auto">We've also included these options in the on-screen controls.  Happy to work through this to a solution with feedback.</p>