3 ms·

We have tinkered with the idea of a native module solely responsible for screen scrape + encode + send, which would further improve performance. Also worth not

We have tinkered with the idea of a native module solely responsible for screen scrape + encode + send, which would further improve performance. Also worth noting is that there's a setting to "reduce power when idle", which throttles screen scraping frame rate when relative CPU utilization is high. Additionally, you can disable "Use full resolution" to turn off Retina support, which should further improve performance for you. We'll work on surfacing these settings better, since it's not obvious that they're buried inside the settings page.

jshier 5y ago
Right, thanks. "Reduce Power When Idle" is always selected, but there's no explanation of what it actually does. I would've expected it to be based off the user being idle in regards to the shared screen (e.g. no input for x time), not based on relative CPU usage calculations. It's hard for the system to increase CPU usage if Pop is already consuming most of it, so I wonder how long it takes for this to actually kick in. "Use Full Resolution" also doesn't explain what it does, so it's unclear how bad the video would get if it was turned off. Even "turn[ing] off Retina support" is unclear, as it doesn't tell me what the alternative is. Does it scale down to the 1x version of the screen? Ideally we'd just have a resolution selector here, for both local and remote. I've also long had issues with the keyboard shortcuts and various settings, again because it's unclear how the settings actually effect anything. I've also encountered bugs where just typing certain characters (I think it was ".") to a remote share toggled my ability to control the remote at all, which was extremely irritating. I really need more explanation of local vs. remote short cuts and which go where and when.
- jsherwani 5y ago
  Thanks for the feedback! You're right, we need to improve each of these significantly. Reduce Power When Idle: decreases the frame rate from 30fps gradually down to 15fps when there's no user activity after a few seconds, and also drops frame rate due to CPU utilization. But you're right, we need to rethink this. Resolutions: yes, it does scale down to 1x, and yes, selecting a resolution would be better. Re: shortcuts, do you remember when it was that you experienced these issues? We had a few bugs around these that have been fixed. We're also working on a revamp of our keyboard handling code for all three platforms to address some of the remaining issues. If you're still running into a specific issue, let us know via hello@pop.com and we'll make sure it's fixed in our keyboard overhaul.
montag 5y ago
Don’t just tinker... make it a grand North Star goal to lose Electron, and make performance your moat.
- jsherwani 5y ago
  Thanks for the provocative phrasing — I really like it! The native module coupled with Electron could be a great solution to the performance issue: it would give native performance for the most critical part of the product, while still providing a cross-platform foundation for a shared user interface across 4 platforms (Mac, Windows, Linux & browsers). Given the feedback today on performance and resource bloat, we're going to dive deeper into benchmarking our product against the competition, and will post an update on what we find.
  - hug 5y ago
    Don't benchmark yourself against other Electron apps. Just promise yourself you'll eventually quit Electron. Electron is nothing more than a deal you make with the devil, selling potential for velocity, only the others are too far gone to even know where they are anymore. When you develop for Electron, you're lured in with an attractive proposition, shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app. As a tradeoff, that's not too bad. You can at least, with just the few of you, get the product out the door sooner rather than later and pick up your first users. You keep going with Electron, because it has the least friction, allowing you to introduce new features and fix bugs at pace you otherwise couldn't sustain. At some point you've listened to the silver tongue'd serpent for a little too long and you've got a slick app with all the value-adds you could want. Also, a giant user base. And that user base consists of people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done. Dragging everyone a little closer to hell if only by the amount of heat of their laptop CPU is putting out. But hey, at least your app is still not as bad as Teams, right?
    - jsherwani 5y ago
      Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1]. Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance. [1] https://news.ycombinator.com/item?id=28230542 https://news.ycombinator.com/item?id=28230542

jshier 5y ago

Right, thanks. "Reduce Power When Idle" is always selected, but there's no explanation of what it actually does. I would've expected it to be based off the user being idle in regards to the shared screen (e.g. no input for x time), not based on relative CPU usage calculations. It's hard for the system to increase CPU usage if Pop is already consuming most of it, so I wonder how long it takes for this to actually kick in. "Use Full Resolution" also doesn't explain what it does, so it's unclear how bad the video would get if it was turned off. Even "turn[ing] off Retina support" is unclear, as it doesn't tell me what the alternative is. Does it scale down to the 1x version of the screen? Ideally we'd just have a resolution selector here, for both local and remote. I've also long had issues with the keyboard shortcuts and various settings, again because it's unclear how the settings actually effect anything. I've also encountered bugs where just typing certain characters (I think it was ".") to a remote share toggled my ability to control the remote at all, which was extremely irritating. I really need more explanation of local vs. remote short cuts and which go where and when.

jsherwani 5y ago
Thanks for the feedback! You're right, we need to improve each of these significantly. Reduce Power When Idle: decreases the frame rate from 30fps gradually down to 15fps when there's no user activity after a few seconds, and also drops frame rate due to CPU utilization. But you're right, we need to rethink this. Resolutions: yes, it does scale down to 1x, and yes, selecting a resolution would be better. Re: shortcuts, do you remember when it was that you experienced these issues? We had a few bugs around these that have been fixed. We're also working on a revamp of our keyboard handling code for all three platforms to address some of the remaining issues. If you're still running into a specific issue, let us know via hello@pop.com and we'll make sure it's fixed in our keyboard overhaul.

montag 5y ago

Don’t just tinker... make it a grand North Star goal to lose Electron, and make performance your moat.

jsherwani 5y ago
Thanks for the provocative phrasing — I really like it! The native module coupled with Electron could be a great solution to the performance issue: it would give native performance for the most critical part of the product, while still providing a cross-platform foundation for a shared user interface across 4 platforms (Mac, Windows, Linux & browsers). Given the feedback today on performance and resource bloat, we're going to dive deeper into benchmarking our product against the competition, and will post an update on what we find.
- hug 5y ago
  Don't benchmark yourself against other Electron apps. Just promise yourself you'll eventually quit Electron. Electron is nothing more than a deal you make with the devil, selling potential for velocity, only the others are too far gone to even know where they are anymore. When you develop for Electron, you're lured in with an attractive proposition, shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app. As a tradeoff, that's not too bad. You can at least, with just the few of you, get the product out the door sooner rather than later and pick up your first users. You keep going with Electron, because it has the least friction, allowing you to introduce new features and fix bugs at pace you otherwise couldn't sustain. At some point you've listened to the silver tongue'd serpent for a little too long and you've got a slick app with all the value-adds you could want. Also, a giant user base. And that user base consists of people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done. Dragging everyone a little closer to hell if only by the amount of heat of their laptop CPU is putting out. But hey, at least your app is still not as bad as Teams, right?
  - jsherwani 5y ago
    Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1]. Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance. [1] https://news.ycombinator.com/item?id=28230542 https://news.ycombinator.com/item?id=28230542