The progress events, that originate from the UploadServer, and are sent to the InputFile component, and then become invocations on the progressListener, and also become render calls if progressRender=true, are based on hard-coded 10% increments in file upload progress. Ideally this would be customised by ICE-3125. But, it would be nice for a sane default, in the absence of configurable progress intervals.

Complicating matters, there's 5 ways for progress events to end up causing renders:

1. progressListener uses RenderManager / OnDemandRenderer
2. progressListener uses PersistentFacesState.render()
3. progressListener uses PersistentFacesState.renderLater()
4. progressRender uses PersistentFacesState.render() for Seam
5. progressRender uses PersistentFacesState.renderLater()

The RenderManager will happen on another thread, meaning that the renders won't delay the actual file uploading, and it will detect and remove redundantly queued render requests. This scenario doesn't really need constrained progress events. It's for the other scenarios.

PersistentFacesState.renderLater() renders on another thread, but does not detect or remove redundantly queued render requests. There is no obvious API to access to enable that functionality. So, one has to constrain the render requests, so that for small files, where the 10% increments are milliseconds apart, there aren't 5 to 8 rendundant render requests queued up, making the page repeated render for a while after the upload has completed.

PersistentFacesState.render() will do the render in the current thread, which will delay the file uploading, taking more total time, on a fast network. But, it solves certain thread local issues. Again, for small files, it's best not to render for ever 10% gain, since we could spend hundreds of milliseconds rendering for every 1 millisecond of file uploading.