The Viper Mini is equipped with the PAW3359. The PAW3359 is based on the PAW3339, which was previously used on the Razer Abyssus Essential and Atheris. According to specifications, the 3359 is capable of up to 8500 CPI, as well as a maximum tracking speed of 300 IPS, which equals 7.62 m/s. Out of the box, five pre-defined CPI steps are available: 400, 800, 1600, 3200, and 6400 CPI.
CPI Accuracy
"CPI" (short for counts per inch) describes the amount of counts registered by the mouse if it is moved exactly one inch. There are several factors (firmware, mounting height of the sensor not meeting specifications, mouse feet thickness, mousing surface, among others) which may contribute to nominal CPI not matching actual CPI. It is impossible to always achieve a perfect match, but ideally, nominal and actual CPI should differ as little as possible. In this test I'm determining whether this is the case or not. However, please keep in mind that said variance will still vary from unit to unit, so your mileage may vary.
I've restricted my testing to the four most common CPI steps, which are 400, 800, 1600, and 3200. As you can see, deviation is decently low, but fairly inconsistent, which is a good result.
Motion Delay
"Motion delay" encompasses all kinds of sensor lag. Any further sources of input delay will not be recorded in this test. The main thing I'll be looking for in this test is sensor smoothing, which describes an averaging of motion data across several capture frames in order to reduce jitter at higher CPI values, increasing motion delay along with it. The goal here is to have as little smoothing as possible. As there is no way to accurately measure motion delay absolutely, it can only be done by comparison with a control subject that has been determined to have the lowest possible motion delay. In this case the control subject is a G403, whose 3366 has no visible smoothing across the entire CPI range.
First, I'm looking at two xCount plots in order to determine whether there is any smoothing present, which would be indicated by any visible "kinks," and if so, at which threshold it kicks in. As you can see, no such kinks can be observed at either 1600 or 8500 CPI, which can mean one of two things: either there is no smoothing or there are no fixed framerate levels. We'll have to take a look at the xSum plots to figure this part out. SPI timing jitter at least is rather low, resulting in clean-looking plots.
Let us see whether the xSum plots are more conclusive then. The line further to the left denotes the sensor with less motion delay. I've plotted 1600, 6400, and 8500 CPI for this test, and all of them show identical motion delay, which indicates that the 3359 does not have any visible smoothing. Curiously, at 8500 CPI the effect of the lens being loose (see below) was significant enough that movement was registered even before I began moving the mouse.
Speed-Related Accuracy Variance (SRAV)
What people typically mean when they talk about "acceleration" is speed-related accuracy variance (or short SRAV). It's not about the mouse having a set amount of inherent positive or negative acceleration, but about the cursor not traveling the same distance if the mouse is moved the same physical distance at different speeds. The easiest way to test this is by comparison with a control subject that is known to have very low SRAV, which in this case is the G403. As you can see from the plot, no displacement between the two cursor paths can be observed, which confirms that SRAV is very low.
Perfect Control Speed
Perfect Control Speed (or PCS for short) is the maximum speed up to which the mouse and its sensor can be moved without the sensor malfunctioning in any way. I've only managed to hit just below 4 m/s (which is within the proclaimed PCS range), at which speed no sign of the sensor malfunctioning can be observed.
Polling Rate Stability
All three possible settings (125 Hz, 500 Hz, and 1000 Hz) show higher than average variance, but it's still well within acceptable limits.
Paint Test
This test is used to indicate any potential issues with angle snapping (non-native straightening of linear motion) and jitter, along with any sensor lens rattle. As you can see, no issues with angle snapping can be observed at any CPI step. 1600 CPI shows no jitter. Minor jitter becomes visible at 3200 CPI and increases significantly at 6400 CPI. Finally, jitter is very high at 8500 CPI. Interestingly, the jitter is more of a fine-grained type, which is unusual. Lastly, significant sensor lens rattle can be seen. The amount of lens movement at 8500 CPI is great enough to register motion without actually moving the mouse. I was able to secure the lens by wedging two paper snippets into the sides. Although this works as a fix, it's not really what I'd expect the average customer doing. A second sample showed no issues in this regard.
Lift-off Distance
The Viper Mini does not support adjusting LOD. The only available (default) setting is medium as it does track at a height of 1 DVD, but not at a height of 2 DVDs. Keep in mind that LOD may vary slightly depending on the mousing surface (pad) it is being used on.
Click Latency
Most computer (and gaming) mice use mechanical switches for the buttons. Mechanical switches need debouncing in order to function as intended, which can add a delay, commonly referred to as click latency. Much like most other recent Razer mice, the Viper Mini is using optical switches for the main buttons. Optical switches do not require any debouncing, hence no delay is added. Unfortunately, this also means I'm unable to conduct my usual click latency testing. Using the less accurate and reliable "bump test," I'm able to measure results that indicate a click latency that is equal to or lower than that of the SteelSeries Ikari, which acts as the baseline (+0.0 ms).
There is an issue, however, that merits further discussion. On mice with mechanical switches the debounce algorithm also takes care of preventing any so-called "slam-clicks"; that is, unintended clicks upon "slamming" the mouse down. The Viper Mini lacks such an algorithm due to the reasons described above, resulting in the need for a different approach. In order to avoid accidental slam-clicks, an artificial delay is added upon lift-off. This delay is only reset after one of the main buttons has been actuated. In practice, this means that when repositioning the mouse, the next click will inevitably be delayed. According to my measurements, this added delay is in the range of +10 ms (relative to Ikari). There is no denying that this is a less than optimal solution. While similar implementations are present on Logitech mice all the same, the delay is reset upon landing, not upon clicking. Razer is aware of this approach being flawed and has developed a firmware which indeed fixes this issue, although it has yet to be released. For this reason, I will refrain from docking any points for this.