The visual footprint of the client is quite big (520x800 px). This PR allows the use to collapse/expand any of the Global stats, Session infos and Last uploaded frame panels to reduce the vertical visual footprint.
Fixed the wrong size detection at client start issue found by Clou.
The method img.getScaledInstance returns null under some conditions (some images cannot be properly managed by Java Runtime), breaking the upload process and reducing the upload queue size in 1.
The process can potentially consume the three concurrent upload slots and hence leaving the client in a zombie state.
* Feature: support for shared downloads directory
This feature is especially relevant for users with several clients running simultaneously within the same computer (computers running several GPUs or any combination of GPUs + CPUs) or multiple computers running in a network. The feature allows the user to specify a shared downloads directory via the new -shared-downloads-dir client option. All the clients using that option will share the same binaries and scene files.
How it works?
The first client downloading a binary or scene will save the file in the directory especified in -shared-downloads-directory. The rest of the clients using the same option will wait until the file has been downloaded. Once the file has been downloaded, it will be ready for the rest of the clients.
This feature is especially relevant for users with metered/slow connections or multiple computers/clients that don't want to download the same binary/file multiple times.
IMPORTANT: All the clients intended to share the binaries and scenes must execute the client with the same -shared-downloads-dir parameter.
* Feature: add session data consumption information in GUI/text UIs
Adds the total bytes downloaded and uploaded in the current session as well as the average data transfer rate for both UL/DL. The information is not added to the 1-line UI as the line will take 150+ characters in the screen.
A new -shutdown <time> option has been created to specify the time when the client will stop asking for new jobs, will finish uploading the frames in the upload queue and will shutdown the computer. The time argument can have two different formats: an absolute date & time in the format yyyy-MM-ddThh:mm:ss (24h format) or a relative time in the format +m where m is the number of minutes from now.
The user can also select the shutdown-mode, where "wait" will wait for all the processes (render + pending uploads) to finish and "hard" will cancel all the pending jobs and will initiate the computer shutdown.
The text UI gets quite messy during the render process, as it takes at least one extra line of the screen per second. This PR fixes that issue and also shows an ASCII bar to show the render progress.
As the value of the askForRendererKill flag is set right after the return of the kill process, under some particular memory and system load circumstances, a race condition occurs and the rendering process in the main thread is closed faster than the process.destroy() returns the control to the thread the called the OS.getOS().kill(process.getProcess()) method. If that condition occurs, the isAskForRendererKill() check returns false (the flag hasn't been set to True in the separate thread) and the execution continues with the frame output check (that doesn't exist as the rendering process was interrupted). The final outcome is a wrong NO_FILE_OUTPUT error instead of the proper RENDERER_KILLED_BY_USER_OVER_TIME.
The fix has been setting the askForRendererKill flag to true before the process is destroyed. If the racing condition occurs, the askForRendererKill will be correctly set.
