Flow control problems

[ondrap]

There seems to be something not quite correct with the way the device is handling flow control. I'm quite deterministically able to induce the following situations:

• run 6 fontSave (for 6 fonts) interspersed with [color, rect, rectf] (progressbar).
  • when there is no progressbar drawing, everything is OK
  • when there is progressbar drawing, the font saving randomly fails
  • when I introduce a small (200ms) delay after each progressbar update, it works OK
• run a bunch of mixed imgSave, layoutSave, layoutDisplayExtended (the order is such that the images and layouts needed for the display are correctly saved) is able to get the glasses in some semi-stuck mode - screen is blank, it doesn't react to e.g. BT disconnection. Introducing small delay before or after each imgSave and layoutSave seems to fix the problem.

It seems to me there is some dependency between 'drawing' and 'saving'. and one doesn't like the other.

Also, is there some way to wait for the send buffer to get empty? It may happen that I get too many commands in queue and instead of building an ever larger backlog, I'd be able to start dropping the display requests in the application. I'd need some way to call flush which would return when the sending queue is empty. Currently I just read some battery status and assume that when I get a value back, everything sent so far was processed. I just wonder if there was some way without the extra roundtrip.

[ondrap]

Another frequent problem is that when I connect to the glasses very early after power-on (before the ActiveLook animation), it turns off. The onConnected handler is called correctly, but I get 4 dots on screen that disappear after a while.

This is likely a result of the direct connection to the glasses, as with the scan-then-connect sequence the connection doesn't probably occur that early in the boot sequence.

[ondrap]

Adding information to the last problem - scan-then-connect won't solve the problem. If the connection happens too soon after the glasses are powered on, they turn off immediately. What seems to help is 'scan - wait 1 second - connect.

[SylvainRomillon]

Another frequent problem is that when I connect to the glasses very early after power-on (before the ActiveLook animation), it turns off. The onConnected handler is called correctly, but I get 4 dots on screen that disappear after a while.

This is likely a result of the direct connection to the glasses, as with the scan-then-connect sequence the connection doesn't probably occur that early in the boot sequence.

This is a firmware known issue, we are working to solve it

[SylvainRomillon]

There seems to be something not quite correct with the way the device is handling flow control. I'm quite deterministically able to induce the following situations:

* run 6 `fontSave` (for 6 fonts) interspersed with [color, rect, rectf] (progressbar).
  
  * when there is no progressbar drawing, everything is OK
  * when there is progressbar drawing, the font saving randomly fails
  * when I introduce a small (200ms) delay after each progressbar update, it works OK

* run a bunch of mixed `imgSave`, `layoutSave`, `layoutDisplayExtended` (the order is such that the images and layouts needed for the display are correctly saved) is able to get the glasses in some semi-stuck mode - screen is blank, it doesn't react to e.g. BT disconnection. Introducing small delay before or after each `imgSave` and `layoutSave` seems to fix the problem.

It seems to me there is some dependency between 'drawing' and 'saving'. and one doesn't like the other.

Also, is there some way to wait for the send buffer to get empty? It may happen that I get too many commands in queue and instead of building an ever larger backlog, I'd be able to start dropping the display requests in the application. I'd need some way to call flush which would return when the sending queue is empty. Currently I just read some battery status and assume that when I get a value back, everything sent so far was processed. I just wonder if there was some way without the extra roundtrip.

We have disabled the command stacking cause we have a firmware known issue. It's fixed in the brunch rc/4.2.1.

Could you provide us logs of data that you send to the glasses ?

[ondrap]

I tried the 4.2.1 branch and it's something like 3-4 times slower. To draw anything slightly complex is just too slow with this version of the sdk.

I will simulate the problems in a few days with the main sdk branch and provide the logs.