{"action":"created","issue":{"url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/790","repository_url":"https://api.github.com/repos/WeakAuras/WeakAuras2","labels_url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/790/labels{/name}","comments_url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/790/comments","events_url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/790/events","html_url":"https://github.com/WeakAuras/WeakAuras2/issues/790","id":364971257,"node_id":"MDU6SXNzdWUzNjQ5NzEyNTc=","number":790,"title":"Throttle \"Display\" code by default","user":{"login":"blooblahguy","id":3236237,"node_id":"MDQ6VXNlcjMyMzYyMzc=","avatar_url":"https://avatars2.githubusercontent.com/u/3236237?v=4","gravatar_id":"","url":"https://api.github.com/users/blooblahguy","html_url":"https://github.com/blooblahguy","followers_url":"https://api.github.com/users/blooblahguy/followers","following_url":"https://api.github.com/users/blooblahguy/following{/other_user}","gists_url":"https://api.github.com/users/blooblahguy/gists{/gist_id}","starred_url":"https://api.github.com/users/blooblahguy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/blooblahguy/subscriptions","organizations_url":"https://api.github.com/users/blooblahguy/orgs","repos_url":"https://api.github.com/users/blooblahguy/repos","events_url":"https://api.github.com/users/blooblahguy/events{/privacy}","received_events_url":"https://api.github.com/users/blooblahguy/received_events","type":"User","site_admin":false},"labels":[{"id":1052359581,"node_id":"MDU6TGFiZWwxMDUyMzU5NTgx","url":"https://api.github.com/repos/WeakAuras/WeakAuras2/labels/%F0%9F%8F%83performance","name":"🏃performance","color":"b75703","default":false},{"id":1012370527,"node_id":"MDU6TGFiZWwxMDEyMzcwNTI3","url":"https://api.github.com/repos/WeakAuras/WeakAuras2/labels/%F0%9F%92%AC%20Discussion","name":"💬 Discussion","color":"ffafd2","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":22,"created_at":"2018-09-28T17:09:34Z","updated_at":"2018-10-03T09:13:18Z","closed_at":null,"author_association":"NONE","body":"**Is your feature request related to a problem? Please describe.**\r\nIt's increasingly common for me to find WAs that do all of their work inside of the display as \"Update Every Frame\". Often times this code is a new loop inside of the OnUpdate, calling UnitAuras or other information and these calls are expensive. i.e. There are multiple Uldir WAs circulating that loop through the raid roster, then loop through 40 for UnitAura with no breaks, all OnUpdate.\r\n\r\n**Describe the solution you'd like**\r\nInstead of novice developers having access to OnUpdate by default, the display update should be throttled to something around every 0.1s. Then experienced developers can create OnUpdate events when they actually need it. This is inverse of how things work now, and shouldn't necessarily break compatibility with existing WAs. Experienced devs can always do what they want within WAs, I think everyone else should have certain best practices \r\n\r\n**Describe alternatives you've considered**\r\nInstead of always throttling, it could be a good idea to make a slider show up when %c is enabled in display with values ranging from 0 (OnUpdate) to 1.0 with 0.1 steps. This at least gives novice developers notice that where this slider is affects performance and gives them an easy avenue to provide better performing WAs.\r\n\r\n**Additional context**\r\nFPS issues in general have been a hot topic, and WAs itself is about as optimized as it can get. Many people just blame the FPS on \"blizzard's change to UnitAura\" but that answer is incomplete. Performance needs to be more front-facing when user's create WAs so that the end users don't just lose FPS and have no idea why without requesting support from devs.\r\n"},"comment":{"url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/comments/426566051","html_url":"https://github.com/WeakAuras/WeakAuras2/issues/790#issuecomment-426566051","issue_url":"https://api.github.com/repos/WeakAuras/WeakAuras2/issues/790","id":426566051,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNjU2NjA1MQ==","user":{"login":"Vrakfall","id":6759520,"node_id":"MDQ6VXNlcjY3NTk1MjA=","avatar_url":"https://avatars1.githubusercontent.com/u/6759520?v=4","gravatar_id":"","url":"https://api.github.com/users/Vrakfall","html_url":"https://github.com/Vrakfall","followers_url":"https://api.github.com/users/Vrakfall/followers","following_url":"https://api.github.com/users/Vrakfall/following{/other_user}","gists_url":"https://api.github.com/users/Vrakfall/gists{/gist_id}","starred_url":"https://api.github.com/users/Vrakfall/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Vrakfall/subscriptions","organizations_url":"https://api.github.com/users/Vrakfall/orgs","repos_url":"https://api.github.com/users/Vrakfall/repos","events_url":"https://api.github.com/users/Vrakfall/events{/privacy}","received_events_url":"https://api.github.com/users/Vrakfall/received_events","type":"User","site_admin":false},"created_at":"2018-10-03T09:13:18Z","updated_at":"2018-10-03T09:13:18Z","author_association":"NONE","body":"@blooblahguy has a point right as this could help the end-user, not versed in the art of coding, to identify displays that are making his interface lag when it shouldn't.\r\n\r\nWhat about detecting an abnormal amount of `OnUpdate` calls, like a certain percentage of frames on which it was used, or detecting if some auras take an abnormal amount of time/CPU time per second and then throw en error if that amount is too high/on every frame? Or both? The bad coder would instantly see something in his code shouldn't be coded that way as a feedback message would be spamming his chat (and maybe his `BugSack`) and the user of those `displays` would be informed that some of his displays are sucking the hell out of his CPU time.\r\n\r\nIt would then be possible to cancel that error throw with a function call with a specific argument: I'm thinking about a boolean or a specific string like \"I acknowledged my code is taking too much CPU time and assert that it is for a justifiable reason.\". That would then require the bad coder to check the documentation where he would be explained why he shouldn't be doing that in the first place, he would then be given the `API` call to make in order to stop the error to being thrown, for genuine usage.\r\n\r\nIt would also allow for easy detection in `wago` of that function call which makes it possible to programmatically alert the end-user that the display is probably doing something terribly non-efficient while leaving the possibility for the author to justify why he couldn't do it another way.\r\n\r\nNow I'm thinking about it, it could also require a button in the display's options in order for the end-user to voluntarily keep using poorly coded ones. The problem being that the bad coder could just check that checkbox and getting away with it without having to check the documentation. A solution could be to open a pop-up (when ticking that checkbox) with information from the documentation telling this is probably wrong. It could also be possible to add a warning like this at importation time for the end-user.\r\n\r\nThis idea just creates the problem for implementing this as to how to detect the abnormal cpu usage: solely referring to the time being used would lead to displays not throwing errors on some machine while throwing it on some others. Though, using a percentage of calls on a certain number of frames should actually trigger the same way along every machine. Maybe there's is even a better detection way.\r\nIt also assumes the author tested his display before publishing it, which is needed for him to acknowledge the error thrown at execution time."}}
{"actor":{"display_login":"Vrakfall"}}