That was painful; hopefully since now it should be easier to have it in every WebGL example.
It's enough to add one line (ideally as the first thing that gets executed):
if ( ! THREE.Supports.webgl ) THREE.Supports.addGetWebGLMessage();
This will add message box with default styling centered near top of the window. Optional parameters "parent" and "id" can be specified for further customization and integration with the document, also message DOM element is returned for easier access.
var messageElement = THREE.Supports.addGetWebGLMessage( { parent: container, id: "my_message" } );
By default, message is added to document.body and has id "oldie" (can be styled with CSS).
Requires to turn off mipmapping to be able to use non-power of two texture.
Effect of texture size on performance is noticeable, also there is no antialiasing (default in Chrome is I think 4x multisampling).
So I guess full-screen postprocessing will be quite costly :(. That's the price of WebGL always running at full-blown high resolution.
This could be somehow mitigated by faking lower resolutions via smaller texture, though I guess it still wouldn't be the same as having lower resolution set by GPU driver (this is a major help with performance in games - I never run full 1680 x 1050).
Rendering proper 3d object into the texture uncovered another issue - framebuffer had to be cleared after switching.
Texture is still flipped :( (original scene has small red torus on the top)
This is proving to be rather tricky. Yet again I tried to handle image coordinate mess in a proper way (UNPACK_FLIP_Y_WEBGL as texture parameter and non-inverted UVs), fixing hacks across the codebase.
This did indeed help with render-to-texture flipping, but instead it created really ugly problems with both normal map and minecraft AO demos. So back to square one :(
Had to set viewport to make it work in OpenGL.
Also made it easier to see texture orientation in the example.
Now it's visible that there is indeed flipping. At least now it's consistent ;).