|
20 | 20 | import org.slf4j.LoggerFactory; |
21 | 21 |
|
22 | 22 | import com.github.sarxos.webcam.WebcamDevice.BufferAccess; |
| 23 | +import com.github.sarxos.webcam.WebcamUpdater.DefaultDelayCalculator; |
| 24 | +import com.github.sarxos.webcam.WebcamUpdater.DelayCalculator; |
23 | 25 | import com.github.sarxos.webcam.ds.buildin.WebcamDefaultDevice; |
24 | 26 | import com.github.sarxos.webcam.ds.buildin.WebcamDefaultDriver; |
25 | 27 | import com.github.sarxos.webcam.ds.cgt.WebcamCloseTask; |
@@ -225,34 +227,61 @@ protected void notifyWebcamImageAcquired(BufferedImage image) { |
225 | 227 | * Open the webcam in blocking (synchronous) mode. |
226 | 228 | * |
227 | 229 | * @return True if webcam has been open, false otherwise |
228 | | - * @see #open(boolean) |
| 230 | + * @see #open(boolean, DelayCalculator) |
229 | 231 | * @throws WebcamException when something went wrong |
230 | 232 | */ |
231 | 233 | public boolean open() { |
232 | 234 | return open(false); |
233 | 235 | } |
234 | 236 |
|
235 | 237 | /** |
236 | | - * Open the webcam in either blocking (synchronous) or non-blocking (asynchronous) mode.The |
237 | | - * difference between those two modes lies in the image acquisition mechanism.<br> |
| 238 | + * Open the webcam in either blocking (synchronous) or non-blocking |
| 239 | + * (asynchronous) mode. If the non-blocking mode is enabled the |
| 240 | + * DefaultDelayCalculator is used for calculating delay between two image |
| 241 | + * fetching. |
| 242 | + * |
| 243 | + * @param async true for non-blocking mode, false for blocking |
| 244 | + * @return True if webcam has been open, false otherwise |
| 245 | + * @see #open(boolean, DelayCalculator) |
| 246 | + * @throws WebcamException when something went wrong |
| 247 | + */ |
| 248 | + public boolean open(boolean async) { |
| 249 | + return open(async, new DefaultDelayCalculator()); |
| 250 | + } |
| 251 | + |
| 252 | + /** |
| 253 | + * Open the webcam in either blocking (synchronous) or non-blocking |
| 254 | + * (asynchronous) mode.The difference between those two modes lies in the |
| 255 | + * image acquisition mechanism.<br> |
238 | 256 | * <br> |
239 | | - * In blocking mode, when user calls {@link #getImage()} method, device is being queried for new |
240 | | - * image buffer and user have to wait for it to be available.<br> |
| 257 | + * In blocking mode, when user calls {@link #getImage()} method, device is |
| 258 | + * being queried for new image buffer and user have to wait for it to be |
| 259 | + * available.<br> |
241 | 260 | * <br> |
242 | | - * In non-blocking mode, there is a special thread running in the background which constantly |
243 | | - * fetch new images and cache them internally for further use. This cached instance is returned |
244 | | - * every time when user request new image. Because of that it can be used when timeing is very |
245 | | - * important, because all users calls for new image do not have to wait on device response. By |
246 | | - * using this mode user should be aware of the fact that in some cases, when two consecutive |
247 | | - * calls to get new image are executed more often than webcam device can serve them, the same |
248 | | - * image instance will be returned. User should use {@link #isImageNew()} method to distinguish |
249 | | - * if returned image is not the same as the previous one. |
250 | | - * |
| 261 | + * In non-blocking mode, there is a special thread running in the background |
| 262 | + * which constantly fetch new images and cache them internally for further |
| 263 | + * use. This cached instance is returned every time when user request new |
| 264 | + * image. Because of that it can be used when timeing is very important, |
| 265 | + * because all users calls for new image do not have to wait on device |
| 266 | + * response. By using this mode user should be aware of the fact that in |
| 267 | + * some cases, when two consecutive calls to get new image are executed more |
| 268 | + * often than webcam device can serve them, the same image instance will be |
| 269 | + * returned. User should use {@link #isImageNew()} method to distinguish if |
| 270 | + * returned image is not the same as the previous one. <br> |
| 271 | + * The background thread uses implementation of DelayCalculator interface to |
| 272 | + * calculate delay between two image fetching. Custom implementation may be |
| 273 | + * specified as parameter of this method. If the non-blocking mode is |
| 274 | + * enabled and no DelayCalculator is specified, DefaultDelayCalculator will |
| 275 | + * be used. |
| 276 | + * |
251 | 277 | * @param async true for non-blocking mode, false for blocking |
| 278 | + * @param delayCalculator responsible for calculating delay between two |
| 279 | + * image fetching in non-blocking mode; It's ignored in blocking |
| 280 | + * mode. |
252 | 281 | * @return True if webcam has been open |
253 | 282 | * @throws WebcamException when something went wrong |
254 | 283 | */ |
255 | | - public boolean open(boolean async) { |
| 284 | + public boolean open(boolean async, DelayCalculator delayCalculator) { |
256 | 285 |
|
257 | 286 | if (open.compareAndSet(false, true)) { |
258 | 287 |
|
@@ -301,7 +330,7 @@ public boolean open(boolean async) { |
301 | 330 |
|
302 | 331 | if (asynchronous = async) { |
303 | 332 | if (updater == null) { |
304 | | - updater = new WebcamUpdater(this); |
| 333 | + updater = new WebcamUpdater(this, delayCalculator); |
305 | 334 | } |
306 | 335 | updater.start(); |
307 | 336 | } |
|
0 commit comments