0034896: Scanning with external barcode scanner performance can be improved

Openbravo Issue Tracking System - Retail Modules

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0034896

Retail Modules

Web POS

public

2016-02-26 14:05

2017-01-17 13:01

Reporter

marvintm

Assigned To

jorge-garcia

Priority

normal

Severity

major

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

RR16Q4.1

Fixed in Version

RR16Q4.1

Merge Request Status

Review Assigned To

marvintm

OBNetwork customer

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0034896: Scanning with external barcode scanner performance can be improved

Description

Currently, the performance of the external barcode scanner when scanning the same product a large amount of times in a row is quite poor, specially in low end machines.

This could be easily improved by "grouping" these requests to ensure that the Web POS has to do less rendering, which in this case takes a significant amount of time.

Another potential improvement consists in ensuring that the event which is generated when a scanning happens is only redirected to the specific component which handles the scanner, instead of the whole window.

Steps To Reproduce

- Configure a fast external barcode scanner.
- Repeatedly scan the same product many times in short time.
- Verify that in low end machines, the Web POS gets stucked, and it takes a bit of time (sometimes even more than half a minute) to add the products, and compute the total amount.

Proposed Solution

B)
to continue fixing the issue:
- create a test that sends that reproduce the "Remark #1" in A). the goal is not to require a physical code scanner and have it in the automation
- fix the issue

C)
create other tests to verify the uses cases specified in A)

A)
There are two optimizations which should be made:
- First optimization consists in ensuring that the scan event only reaches the component which will actually use this event. This removes the significant overhead that Enyo introduces when receiving and handling events, particularly when there are many components rendered in the page.

- Second optimization consists in grouping products received very quickly. To do this, a small delay should be introduced whenever the first product is added. The idea is to group this requests, and initiate a single "add product" action whenever the user has stopped adding products.

These two optimizations are implemented in patches keyboard1_mobilecore.diff and keyboard1_posterminal.diff

Remark #1: Currently the implementation of the second optimization is not fully correct!! At this point, it only handles the case of the same product being added very quickly (right now it will add all units for the last product). A change to the implementation should be done so that it handles additions of different products very quickly.

Remark #2: It's very important to consider the case of modules which may have added hooks to the PreAddProduct hook, or any other hook that may take place during the process of adding products.

Remark #3: It's very important to test that non-grouped products work correctly after these changes. Optimization #2 most likely will not work for them, but at least the functionality should not be broken.

Additional Information