Parsing of an STL ASCII file could be much faster

4 thoughts on “Parsing of an STL ASCII file could be much faster”

1. @jostschmithals

   Would you please try to add

   if ( window.TextDecoder !== undefined ) {
   
       return new TextDecoder().decode( array_buffer );
   
   }
   

   after

   var array_buffer = new Uint8Array( buf );
   

   in STLLoader

   three.js/examples/js/loaders/STLLoader.js

   Line 247
   in
   6028312

   var array_buffer = new Uint8Array( buf );

   and see how the performance with your 40MB file will be?

2. @takahirox

   … and see how the performance with your 40MB file will be?

   The result is excellent! – Adding

   if ( window.TextDecoder !== undefined ) {
   
       return new TextDecoder().decode( array_buffer );
   
   }
   

   improves the time needed on my system for executing the ensureString function

   • on Chrome from 12 seconds before to 0.12 seconds afterwards
   • on FF from 5-6 seconds before to 0.17 seconds afterwards

   (with the previously tested 40MB STL ASCII file, on Windows 10)

   – and in spite of this the model looks exactly like before 😉

3. Do you folks think we need loader.setResponseType() or something for
   browsers which don’t support TextDecoder?

   Getting specific, that’s IE 11 and Microsoft Edge[1]. I’d encourage interested persons to upvote the issue here. It is marked as “under consideration” currently.

   My preference would be to not add setResponseType() if it’s purely an optimization for one vendor. Setting a “text” response type for a binary .glb will not work, so it seems likely to confuse people in addition to adding code paths we must maintain.

   • [1] Excluding Opera Mini, which doesn’t support WebGL anyway.

4. TextDecoder API is now in progress on Microsoft Edge, as well: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6558040-support-the-encoding-api 🙂

Comments are closed.