Having two separate TF trees (which is what is shown in your screenshot) is not correct for a single robot. Your _1 suffix for the frames based on your encoders is the root cause of the issues you have with gmapping. Take a look at REP 105 for some details on standard frames in ROS, but I'll detail how you should fix your frames below.
First off, since your Kinect is connected to the robot's base at some point and doesn't just sort of float, your transform should be between openni_camera and base_link, not between openni_camera and odom. Next, your encoders (possibly fused with any other relative type sensors like a gyro or visual odometry using something like robot_pose_ekf) should determine the transformation between base_link and odom. gmapping then publishes the odom to map transform so that you can localize your robot in the fixed map reference frame. You can check that your localization is ready for gmapping if, in rviz, you can set your fixed frame to odom and view your LaserScan output while driving the robot around. If you set rviz to buffer some amount of scans, you should get something that approximates a map of your environment.
gmapping doesn't output a base_link to odom transform at all (that's what your encoders are generating) - it uses that transform to determine how far your robot has moved between scans. gmapping only outputs the odom to map transform, so it cannot "overwrite" the base_link to odom transform.
Once you correct your TF tree, you should be able to use the default gmapping temporal update parameters. You had to enable that to force updates after a certain amount of time because, since your encoders were publishing in a separate TF tree, gmapping was waiting for your robot to move (as indicated by some amount of difference in the base_link to odom transform, which is what the linearUpdate and angularUpdate parameters control).
If you want to figure out how much error there is in your odometry from the encoders, you could look at how much the gmapping correction (odom to map transform) drifts over time. In an ideal situation, and assuming gmapping doesn't move it's origin point while you are mapping, the drift in the odom to map transform should be zero.
Why are you adding the _1 suffix to frames from your encoders? What is supplying your base_link->odom transform (the not suffixed versions)? Some other odometry source?
I added the suffix to distinguish it from the corrected odom supplied by slam_gmapping, to elicit the encoder errors. However, I don't recall being able to visualize it properly, so I think there's a (logical) flaw in that system. Does slam_gmapping overwrite the odom published by the encoders?