Light Update Lag for Alienware Devices

[helloar14]

Since the previous problem is already solved, I think it's better to open a new issue thread for the lag problem.

I've put the log files for several games that I've tested into a Google Drive folder (https://drive.google.com/folderview?id=0B1_W4J7s2inxfjBqWTBKQkxuYjZNODNGZ1pOSHVYT1RSazRYOUowNVFPUVZmNzBJbDJiUk0&usp=sharing)

Alongside the lag, it seems that some command did not transfer properly. For example in XCOM, when it's enemy turn the light is supposed to go red, but sometimes only the keyboard go red, while the laptop and/or GA stayed blue. In The Talos Principle, when we're entering a puzzle room, the light is supposed to go green/red/yellow etc. depending on the sigil, but sometimes the laptop and/or GA stayed white.

Again, thanks for this awesome plugin! You rock, man!

[Archomeda]

I'm completely clueless. It seems that the colors are processed correctly (well, at least they are logged correctly). I get the feeling there might be an issue when forwarding the colors to Alienware. At least it's consistently Alienware devices. I'll check if I can find anything.

Another small thing that I noticed that might not even be related to this problem, but LFXE can't properly get the light locations from LFX. Instead, it will be set to some trash value. This is not supposed to happen and I will at least fix that.
Edit: Actually, that's just a small display bug in the log. It is correctly set to zeros internally.

[Archomeda]

Hey again!

I updated the code to include some more logging when updating the lights. Can you test the latest version again? I hope to get more results from this.

[helloar14]

Okay, I've uploaded the latest testing results in the folder (the new files are marked with LightFXE version number).

[Archomeda]

Well... at least some of the log changes that I did are correct. But other than that, it would seem that every color update to Alienware devices is not failing. Have you also checked without the debug log being enabled? It's possible that because of this, the process is too busy writing to the logs and is therefore lagging behind.

I noticed that you've tried 6 games. Can you say specifically what colors each game should have, but doesn't have? You've only mentioned XCOM and The Talos Principle so far.

Besides that, I should probably set a mutex on the logger. It seems it logs multiple lines at the same time that breaks the formatting a bit and makes things less readable.

[helloar14]

Yeah, I tried reading the log mid-game, but it seems that the command did get executed after all.

Anyway, here are the specifics for each game:

• In Shadow of Mordor, the light defaults to purple, but when you're entering Wraith World, the light changes to white; when you're poisoned the light changes to blinking green; when you're low on health the light changes to blinking red.
• In Metro 2033, the light matches ambient light in-game (akin to ambilight).
• In Dungeon Siege III, the light matches your HP (from green to red).
• In Shadow Warrior... well, i just know that sometimes the light go red. I think the original implementation (without LFXE) itself is quite shonky.

I tried using my laptop only without Graphics Amplifier and Logitech Keyboard, and the light seems to be working fine; no lag whatsoever. I'll try adjusting the log settings and testing different configurations in the future.

Anyway, thanks for the update :)

[Archomeda]

Yeah, I tried reading the log mid-game, but it seems that the command did get executed after all.

Reading the log while in-game can be tricky, especially with the massive amounts of updates happening.
Just to be clear, is there still a problem with no light updates, or is it just a matter of having delays or no synced colors across devices?

---

I just realized that it's entirely possible that the game uses so much of your CPU time, that LFXE doesn't get enough CPU time to update some of the colors.

The way how LFX works, is that it sets a color of a specific light. Afterwards, when Update is called it pushes the previously set color to the device.
LFXE intercepts those calls. It queues the request to change the colors, and updates it on the device when necessary (when Update is called). But every device should have its own thread. When an update is needed, this thread should wake up and perform the necessary actions on that device.
Since you have 3 devices, it has 3 threads. I'm not sure about your CPU and how many threads it supports. But if, for example, a game uses 2 threads, and your CPU supports 4 threads, it has 1 thread too few.

I'm not entirely sure if this is the issue. A thread should not be suspended for, let's say, 3 whole seconds when it has been signaled to the OS that it wants to wake up. It can, however, get a couple of milliseconds delay, which might cause the color updates to be not synced as you would expect.

Can you try to test this theory by only enabling one of the devices every time. If every individual device is working fine without (too much) delay, but multiple devices together are delayed (in whatever combination), then I will have a look if I can improve this somehow.

---

Small note, I've added milliseconds to the log and also fixed some weird initialization issue that somehow affected release builds on my end, but apparently not on your end as LFXE worked correctly already 😕
So, if you want, you can use the newest build and test it.

[helloar14]

Yes, this is just a matter of having delay or no synced color across devices.

And yes, I can confirm that enabling fewer devices did help the performance. Using the keyboard and Graphics Amplifier only yielded lesser lag than keyboard and laptop (maybe because the number of light zones in the laptop is higher?) but overall, using any combination of two devices only instead of three devices did produce better performance.

[EDIT] FYI, Alienware 13's CPU is indeed a weak i7 ULV (5500U)

[Archomeda]

I'll change the way how the color updates work. As I said in my previous comment, currently every device gets its own dedicated thread that manages the lights. I'm thinking of changing it to only one thread that updates the lights of all devices sequentially. This involves some code overhaul, which will take some time, because there is some other stuff in the code that will not work as expected when I change it globally.

[Archomeda]

Okay, I've moved around some code that made this change possible. Can you check if it's working better with the latest build?

[helloar14]

It's working far better, although the lag and mismatch issue still persists. Thank you very much!

Now the laptop and keyboard is always nearly in sync (just a liiiiiitttle lag for the laptop), but the graphics amplifier still experience mismatched colours.

I've attached a new log (playing The Talos Principle) where it's very noticeable when a mismatch happened, because the game rarely updates the color (only when changing rooms).

But then again, after checking the logs, it appears the command did get executed correctly, even with the Graphics Amplifier.

Anyway, thank you very much!

[Archomeda]

That's great! The little mismatch can happen since it's updating sequentially. There might be some milliseconds delay, but there should be less variance. Regarding the log, it seems you uploaded the wrong one. This one is still build 121 and from Metro 2033 Redux.

Edit: Small update, I also implemented an async logger. This means that LFXE doesn't have to wait on messages to be written to the log file anymore (as writing something to disk can be very slow compared to other tasks!). These messages are stored in memory until the dedicated logger thread processes it. So you can now use the debug log without having your game or the updates to the lights being slowed down. A nice side effect of this, is that you get more accurate log times now 🎉

[Archomeda]

Since there are no updates on this issue and I've released v0.5.0 a couple of days ago, I'm closing this. If there's still an issue, feel free to reopen it.