Dayon! Français

Support

Use the following forums to post any question or report any bug.

Known Limitations

JAVA Process Properties

On Windows, I'm using Launch4J to wrap the main JAVA class into an .exe file. You can still configure the JVM of each process using the corresponding .l4j.ini file within the bin directory of your Dayon! install.

You can for example setup the JVM RAM usage taking into account the size of the cache and whether or not you're using the LZMA compression method (requires more RAM on the assisted side).

The -server option is available if you're using a JDK (as opposed to a JRE).

On Unix, the same options are available within the dayon.sh script.

Dayon! Home Directory

The directory .dayon is created within the directory referenced by the JAVA property user.home and contains the saved user preferences and default log files.

CRC Checksum

On the assisted side, the screen is divided into different areas called tiles. Only tiles that have changed from the previous capture are sent over the network to the assistant side. To determine if a tile is different I'm currently computing a CRC code (i.e., a unique integer value representing the pixels of the tile) that is not perfect for the sake of speed. So it might happens that some changed tiles are not sent to the assistant.

Until now I've detected that issue during strong testing for very few pixels. Visually, I've not noticed anything serious. But in case things are going mad you can then restart the assisted or before try the reset action (the orange lightning icon) that should clear every cached data and resend a full screen capture from scratch.

Statistics Counters

Dayon! Assistant : Statistics

The status bar of the assistant frame is displaying a set of counters.

  1. Network Bandwidth
  2. Compression Ratio: how many times the initial capture (diff only) has been compressed
  3. Number of Tiles: the number of tile being transmitted over the network as well as the cache hits.
  4. Number of Skipped Capture: the number of screen captures that have been skipped because of a too high rate (i.e., low tick value) for the CPU. To minimize that number you have to slow down the capture rate using a bigger tick value.
  5. Number of Merged Capture: the number of screen captures that have been merged before being transmitted. This is due to a capture rate too high for the current compression method. To minimize that number you have to slow down the capture rate and/or change the compression method using a faster one.