Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 24 23:59
    QuiNz0r opened #281
  • Jul 03 17:03
    poveden commented #279
  • Jun 18 19:31

    Sharparam on 6.0.0

    Disable coverage reports on Tra… Update GitHub target in Cake I… Use Cake in GitHub actions (compare)

  • Jun 18 19:21

    Sharparam on 6.0.0

    Fix invalid table formatting (compare)

  • Jun 18 19:20

    Sharparam on 6.0.0

    Add note in readme about pre-re… Configure indent size for markd… Make top of README prettier and 8 more (compare)

  • Jun 18 18:22

    Sharparam on 6.0.0

    Use dotnet tool version of Repo… Move coverage report generation… Add zip of coverage report and 2 more (compare)

  • Jun 18 16:47

    Sharparam on 6.0.0

    Fix commented code (compare)

  • Jun 18 15:59

    Sharparam on 6.0.0

    Fix old paths in GitHub Actions… Fix parameter parsing in build.… (compare)

  • Jun 18 15:36

    Sharparam on 6.0.0

    Switch to using Cake as a dotne… Use GitVersion as a dotnet tool Use uppercase "V" for verbosity and 5 more (compare)

  • Jun 18 01:14

    Sharparam on gh-pages

    [AUTOMATED] Documentation updat… (compare)

  • Jun 18 01:11

    Sharparam on v6.0.0-rc14

    (compare)

  • Jun 18 01:02

    Sharparam on 6.0.0

    Fix glob pattern in cache key Update artifact paths (compare)

  • Jun 18 00:48

    Sharparam on 6.0.0

    Fix glob paths for artifacts (compare)

  • Jun 18 00:45

    Sharparam on 6.0.0

    Upgrade Travis dist to bionic Enable main GitHub Action workf… Create some artifacts in GitHub… (compare)

  • Jun 18 00:12

    Sharparam on 6.0.0

    Fix caches Remove Coveralls integration Add GitHub Actions workflow (compare)

  • Jun 17 23:58

    Sharparam on 6.0.0

    Handle RC tags in docs script Skip restore when running tests Remove outdated code and 2 more (compare)

  • Jun 17 20:08

    Sharparam on 6.0.0

    Add missing newline Add OldStyle option back to Ope… (compare)

  • Jun 17 20:00

    Sharparam on 6.0.0

    Use Path32 register mode for Op… (compare)

  • Jun 17 19:55

    Sharparam on 6.0.0

    Update OpenCover settings (compare)

  • Jun 17 19:32

    Sharparam on gh-pages

    [AUTOMATED] Documentation updat… (compare)

Bart van Vliet
@Kapulara
@Sharparam thank you so mutch! :heart:
Adam Hellberg
@Sharparam
these are for WPF keys, mind
you'll have to adapt it to the enum WinForms uses
Brandon Scott
@brandonscott
That must have been tedious @Sharparam
Adam Hellberg
@Sharparam
determination is a hell of a drug
Adrian
@WolfspiritM
Heya. :-) Till now I've send updates to the Keyboard all at once including sending already set Keys with Chroma.Instance.Keyboard.SetKeys(keys, Color); today I noticed that sometimes a change is not successfully send to the keyboard somehow. It seems to be random to me when it works and when it doesn't. If I repeat the SetKeys a few times in my method it always works (but that's just ugly). For now I've included a ColorCache to only send the keys that changed and that seems to work. Is there a known issue or limit of updates within a second (even so I don't think I'm hitting that)? Or can this have something to do with Threading? A lock around the SetKeys didn't work either.
Brandon Scott
@brandonscott
It should work every time you set it without doubt
there's no rate limiting
@Sharparam any thoughts?
Adrian
@WolfspiritM
Hm that's weird then. I even logged the request to setkeys and I'm pretty sure setkeys is called with the right color and key. But the Keyboard doesn't set the Color. A few calls later it finally does.
Adam Hellberg
@Sharparam
in WaM with frequent updates it would not always register every change (~250ms between changes). havent' checked with latest updates but if brandon could get 24fps working which is an update every ~41.67 seconds then anything down to at least that delay should work fine
milliseconds*
41.67 milliseconds
Adrian
@WolfspiritM
Sometimes there are updates every half a second for me and it seems to work with just a few keys. Just all Keys at once seem to be causing issues.
Adam Hellberg
@Sharparam
how are you performing the update when changing all keys
Adrian
@WolfspiritM
Multiple Chroma.Instance.Keyboard.SetKeys(new List<Key> { Key.W, Key.A, Key.S, Key.D }, Color1); for each color
Adam Hellberg
@Sharparam
a cache of some sort might be more performant in reducing the number of created objects on the heap, but it shouldn't be related to the issue. it should just change the speed of updates if there are a lot of such new object creations
is this single- or multithreaded app?
Adrian
@WolfspiritM
It's Multithreaded...using Tasks
Adam Hellberg
@Sharparam
@brandonscott are your updates in your apps handled by their own threads separate from main thread?
Brandon Scott
@brandonscott
No
And I haven't tried the thread safe implementation you've done across multiple threads
But no, all of my keyboard updates are from the main thread normally
Adrian
@WolfspiritM
Could be a problem with the Taskhandling then. Maybe it only works on the first Thread that calls Chroma while other Tasks under load might be opened on another thread in the threadpool
Adam Hellberg
@Sharparam
isn't EA using a separate thread for updates
@WolfspiritM it could be worth making a test having only one thread handle keyboard updates, and see if it experiences the issue
i'm taking it you're firing of several one-off threads (tasks) that do one update and die?
Brandon Scott
@brandonscott
No it's not @Sharparam as we hadn't implemented the thread safety at that point
So it was all using dispatcher timer
Adam Hellberg
@Sharparam
dispatcher-timer does the tick on a separate thread doesn't it
Brandon Scott
@brandonscott
Yes but it's intrinsically linked to the UI
But yes you are rigbt
Rigbt
Adam Hellberg
@Sharparam
hence why you need to make use of the invoker if doing UI updates from a dispatchertimer tick since it's not running on UI thread
Brandon Scott
@brandonscott
*right
Correct to some extent, you can make a dispatcher timer run on the UI thread though
It's one of the unique features for it
Adrian
@WolfspiritM
I'm handling some Network Stuff in different Tasks then fire the update with an event which should still be in the same Task and Thread.
Will try to sync them back to the UI Thread
Adam Hellberg
@Sharparam
not entirely sure how C#/.NET handles event threads
firing an event will run the event handler in its own thread, but how those threads are managed and if they are re-used i'm not sure
maybe we should get jon skeet in here lol
@brandonscott make it happen
Adrian
@WolfspiritM
According to System.Threading.Thread.CurrentThread.ManagedThreadId right before SetKeys it's always the same Thread.
However...I will try a few more things tomorrow. For now I need to go. Thanks for the help! :-)
Adam Hellberg
@Sharparam
always
Adrian
@WolfspiritM
Okay. I tried one last thing...making my color changes in a simple winforms app. I have the same problem there including a repro. That seems to be an issue somewhere deeper. Not sure if in Corale or even deeper in the SDK. Here is my repo: http://pastebin.com/X935yS6E
The funny thing is if you remove or add one Key somewhere...it works again
but as it is there...it only displays parts