9 ms·

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't apply to VS Code's cursor.

Touche 10y ago
I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.
- nolok 10y ago
  > I'm not sure why this implementation is slow I'm guessing the culprit for that is in this part of the bug report: > Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) As for > why they needed to implement it themselves and not let the OS handle the blinking cursor They're not editing inside a text editor field anymore, they need to blink on html. I guess they're not using a deprecated <blink> tag is because it's not customizable in any way.
  - kibwen 10y ago
    I don't believe that any modern browser still supports the blink tag; IIRC Firefox was the last to get rid of it, a year or two ago. You can hack it up in CSS, though.
    - ethbro 10y ago
      Truly, the web has come full circle.
  - Touche 10y ago
    Thanks, so they are probably not using a contenteditable element. In that case it makes sense that they would need to use a CSS animation to blink the cursor.
  - Mister_Snuggles 10y ago
    On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. The sample program builds a basic text editor without cheating and using a textbox control. I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms648398(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
    - coldtea 10y ago
      >On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. (...) I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? The "built in text edit control" IS a native text field already.
      - Mister_Snuggles 10y ago
        My point is that the built-in text edit control needs some way to draw it's caret, so surely a universal method to draw a blinking caret exists somewhere.
        coldtea 10y ago
        Well, they could just make a C extension to Electron that draws a blinking colored line (that's all it is) using the OSes arbitrary drawing facilities. No need to have an official OS caret function (especially if you're not a native text field, and caret aside, the rest of your text editing will be different/broken in subtle ways compared to the OS).
        Someone 10y ago
        I'm not aware of any system where one can create that caret without a text edit control to hold it. That means that, if the standard text edit control isn't suited for what you want to do, you can't have the caret. Certainly, on the original Mac OS (a system on which I worked on OS patches for detecting the location of the caret) the method that application used for drawing the caret varied widely. I've seen it implemented by drawing a line, by drawing a rectangle, either in one go or in two parts (that happened in applications that supported a split caret, even if the caret wasn't split), with various transfer modes. Slanted carets typically were application-specific, too.
- azrazalea 10y ago
  > why they needed to implement it themselves and not let the OS handle the blinking cursor. Probably because they are using electron.
- billconan 10y ago
  this is exactly the same problem I met yesterday. I made a webpage based on a bootstrap template On this webpage, I have 2 realtime components. one is a chart, based on dygraphs the other component is a bootstrap progressbar. the bootstrap progressbar is made by html divs: https://www.w3schools.com/Bootstrap/bootstrap_progressbars.asp https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a... Both components are updated in realtime by a websocket. I noticed that the chart by itself is very fast. But as soon as the progressbar is added, the entire webpage and even the entire machine becomes very slow. I guess this is because every bit of progressbar update, the browser rerender the entire page, as the progressbar is a div. I don't know how to solve this. I thought about using react for its virtual dom. but if eventually I need to update the dom, the speed seems to be the same.
  - scriptproof 10y ago
    There is an HTML 5 progress tag supported by all browsers: <progress id="" max=100>
  - jinglebells 10y ago
    Can you buffer the incoming websockets data and only update at a small percentage of the inputs or maybe based on time? Lodash has a debounce function which is useful to throttle UI features hooked to incoming data. https://css-tricks.com/debouncing-throttling-explained-examples/ https://css-tricks.com/debouncing-throttling-explained-examp... You never really want the UI repaint to be dictated by data, it's better to use timers.
- paulirish 10y ago
  Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 http://crbug.com/361587. So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work. I think the added visibility on this topic will likely escalate the priority of the fix. :) * Simple text editors, and basic ones built on [contenteditable] can, but those rarely scale to the feature set most want. (I work on the Chrome team, though not on the rendering engine)
  - Kristine1975 10y ago
    >http://crbug.com/361587 http://crbug.com/361587 Reported almost 3 years ago and still not fixed...
  - pcwalton 10y ago
    Why are you even painting at all instead of layerizing it? (This is a perfect example of what I've been increasingly convinced of lately: that the whole "paint"/"compositing" distinction hurts the Web…)
  - phkahler 10y ago
    >> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Powerful features do not require retarded implementations.
  - Mister_Snuggles 10y ago
    > Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for those that don't need it. [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms648398(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- fegu 10y ago
  Am I the only one around here who prefers a nonblinking cursor. That and key repeat rate are my first setting on any new install.
tinus_hn 10y ago
iTunes has the same issue with its spinner while syncing, it takes about 20% CPU time.
- coldtea 10y ago
  Who said it's the spinner in that case? After all, it IS syncing at that time, which means it does a lot of stuff. Whereas the issue here is with the caret shown when the editor is idle.
  - tinus_hn 10y ago
    Activity Monitor allows you to easily profile what the application is spending its CPU time on and it shows that iTunes spends an excessive amount of its time on updating the UI, specifically the spinner.
jcwayne 10y ago
In the early days of working on my current main project, I found that updating a progress bar was slowing the process it was monitoring. Since there were times when it was useful to see near real-time progress, I added added a slider which allows the user to adjust the sampling rate. That slider is affectionately known (by me anyway) as the Heisenberg Compensator. P.S. I have sped up my shit. That process originally took days, now it takes an hour.
- m-p-3 10y ago
  > Heisenberg Compensator That's a perfect name, I love it.
  - fapjacks 10y ago
    There's a Heisenberg Compensator in Star Trek transporters [0] [0] http://www.startrek.com/database_article/heisenberg-compensators http://www.startrek.com/database_article/heisenberg-compensa...
    - jcwayne 10y ago
      Not a coincidence.
- maccard 10y ago
  It's fairly regular in my field (game dev) to put some debugging/instrumentation code in and only enable it for one frame after a key is pressed.
Zenst 10y ago
IBM spent a humongous amount of man hours upon the running man in smit under AIX, many of those consumed with making sure it ran correctly on all systems of various speeds without the animations going crazy. Alas I don't have exact man hours, but that was what one of the engineers told me a nearly 2 decades ago now. Hopefully somebody else has more detail upon this as one of the earliest examples of progress animations that still runs today that I'm aware of. I still hark back to the days of the C64 and the likes in which had tape storage and was common to have a game as a loading screen to play. Was a small program and used to give the user something to do whilst they waited 20 minutes for the program to load. Many also rewrote the cassette storage code for faster storage/loading and would often be a case of loading that program with the small game like space invaders that you could play whilst the main game loaded utilising the quicker tape handling code.
- krylon 10y ago
  Broken Sword let you play Breakout during the installation; it was such fun (I had not played Breakout in a long time at the point) I was almost sad when the installation was finished. ;-) I have often wondered since why this was not a more popular way to deal with long running installers.
  - royjacobs 10y ago
    Having minigames during loading or installation was actually patented by Namco for Ridge Racer, I believe. I'm not quite sure about the details since I seem to recall things like invade-a-load on my Commodore 64 at least a decade earlier, but there you go.
    - Cpoll 10y ago
      Expired in 2015 :) When I was younger, it seemed so obvious to add a minigame to a long loading screen, I had assumed that there were technical reasons for not doing it.
  - aerique 10y ago
    I think it's because Namco had a patent on games in loading screens from 1995 to 2015: http://kotaku.com/the-patent-on-loading-screen-mini-games-is-about-to-exp-1744705351 http://kotaku.com/the-patent-on-loading-screen-mini-games-is...
peckrob 10y ago
This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner in it when you ran it with verbose options. At the time I was on a slow dialup connection as I was on break from school, and something weird would happen. Every time I ran the script to test it, my Internet connection would become nearly unusable. But as soon as the script finished, it would suddenly start working again. As you can imagine, this was very confusing since the script was running entirely on a remote system. What the hell is going on? This stumped me for an hour or so until I ran it without the verbose option ... and it didn't happen. Then I finally realized what was happening: I was refreshing the spinner on EACH ROW and remote machine was going through the rows so quickly that sending refreshes for the spinner saturated my tiny dial-up connection. Changing this to only update once a second fixed it entirely. And that's how I DoS'd myself with a spinner.
- kelvin0 10y ago
  Nice foot gun story. If you had a T1 at the time, you would never had noticed such a pitfall.
  - peckrob 10y ago
    Pretty much, yeah. I never noticed it on campus because I was sitting on a 10 megabit connection. That added an extra dimension to the confusion because I was sure this never happened when I was on campus, only when I was sitting 300 miles away. It was still happening if I had bothered to look at the network stats, just not enough to entirely saturate the connection.
  - agumonkey 10y ago
    I often advise to write code on "obsolete" tech. It makes every bit of cruft obvious.
    - 10y ago
tmsldd 10y ago
Minimizing the installation window would prevent the paint event and your installation would finish quickly...

Touche 10y ago

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

nolok 10y ago
> I'm not sure why this implementation is slow I'm guessing the culprit for that is in this part of the bug report: > Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms) As for > why they needed to implement it themselves and not let the OS handle the blinking cursor They're not editing inside a text editor field anymore, they need to blink on html. I guess they're not using a deprecated <blink> tag is because it's not customizable in any way.
- kibwen 10y ago
  I don't believe that any modern browser still supports the blink tag; IIRC Firefox was the last to get rid of it, a year or two ago. You can hack it up in CSS, though.
  - ethbro 10y ago
    Truly, the web has come full circle.
- Touche 10y ago
  Thanks, so they are probably not using a contenteditable element. In that case it makes sense that they would need to use a CSS animation to blink the cursor.
- Mister_Snuggles 10y ago
  On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. The sample program builds a basic text editor without cheating and using a textbox control. I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms648398(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
  - coldtea 10y ago
    >On Win32[0], the blinking caret can be shown anywhere inside a window, not just on a text field. (...) I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret? The "built in text edit control" IS a native text field already.
    - Mister_Snuggles 10y ago
      My point is that the built-in text edit control needs some way to draw it's caret, so surely a universal method to draw a blinking caret exists somewhere.
      - coldtea 10y ago
        Well, they could just make a C extension to Electron that draws a blinking colored line (that's all it is) using the OSes arbitrary drawing facilities. No need to have an official OS caret function (especially if you're not a native text field, and caret aside, the rest of your text editing will be different/broken in subtle ways compared to the OS).
      - Someone 10y ago
        I'm not aware of any system where one can create that caret without a text edit control to hold it. That means that, if the standard text edit control isn't suited for what you want to do, you can't have the caret. Certainly, on the original Mac OS (a system on which I worked on OS patches for detecting the location of the caret) the method that application used for drawing the caret varied widely. I've seen it implemented by drawing a line, by drawing a rectangle, either in one go or in two parts (that happened in applications that supported a split caret, even if the caret wasn't split), with various transfer modes. Slanted carets typically were application-specific, too.
azrazalea 10y ago
> why they needed to implement it themselves and not let the OS handle the blinking cursor. Probably because they are using electron.
billconan 10y ago
this is exactly the same problem I met yesterday. I made a webpage based on a bootstrap template On this webpage, I have 2 realtime components. one is a chart, based on dygraphs the other component is a bootstrap progressbar. the bootstrap progressbar is made by html divs: https://www.w3schools.com/Bootstrap/bootstrap_progressbars.asp https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a... Both components are updated in realtime by a websocket. I noticed that the chart by itself is very fast. But as soon as the progressbar is added, the entire webpage and even the entire machine becomes very slow. I guess this is because every bit of progressbar update, the browser rerender the entire page, as the progressbar is a div. I don't know how to solve this. I thought about using react for its virtual dom. but if eventually I need to update the dom, the speed seems to be the same.
- scriptproof 10y ago
  There is an HTML 5 progress tag supported by all browsers: <progress id="" max=100>
- jinglebells 10y ago
  Can you buffer the incoming websockets data and only update at a small percentage of the inputs or maybe based on time? Lodash has a debounce function which is useful to throttle UI features hooked to incoming data. https://css-tricks.com/debouncing-throttling-explained-examples/ https://css-tricks.com/debouncing-throttling-explained-examp... You never really want the UI repaint to be dictated by data, it's better to use timers.
paulirish 10y ago
Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587 http://crbug.com/361587. So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work. I think the added visibility on this topic will likely escalate the priority of the fix. :) * Simple text editors, and basic ones built on [contenteditable] can, but those rarely scale to the feature set most want. (I work on the Chrome team, though not on the rendering engine)
- Kristine1975 10y ago
  >http://crbug.com/361587 http://crbug.com/361587 Reported almost 3 years ago and still not fixed...
- pcwalton 10y ago
  Why are you even painting at all instead of layerizing it? (This is a perfect example of what I've been increasingly convinced of lately: that the whole "paint"/"compositing" distinction hurts the Web…)
- phkahler 10y ago
  >> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Powerful features do not require retarded implementations.
- Mister_Snuggles 10y ago
  > Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for those that don't need it. [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms648398(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
fegu 10y ago
Am I the only one around here who prefers a nonblinking cursor. That and key repeat rate are my first setting on any new install.

tinus_hn 10y ago

iTunes has the same issue with its spinner while syncing, it takes about 20% CPU time.

coldtea 10y ago
Who said it's the spinner in that case? After all, it IS syncing at that time, which means it does a lot of stuff. Whereas the issue here is with the caret shown when the editor is idle.
- tinus_hn 10y ago
  Activity Monitor allows you to easily profile what the application is spending its CPU time on and it shows that iTunes spends an excessive amount of its time on updating the UI, specifically the spinner.

jcwayne 10y ago

In the early days of working on my current main project, I found that updating a progress bar was slowing the process it was monitoring. Since there were times when it was useful to see near real-time progress, I added added a slider which allows the user to adjust the sampling rate. That slider is affectionately known (by me anyway) as the Heisenberg Compensator. P.S. I have sped up my shit. That process originally took days, now it takes an hour.

m-p-3 10y ago
> Heisenberg Compensator That's a perfect name, I love it.
- fapjacks 10y ago
  There's a Heisenberg Compensator in Star Trek transporters [0] [0] http://www.startrek.com/database_article/heisenberg-compensators http://www.startrek.com/database_article/heisenberg-compensa...
  - jcwayne 10y ago
    Not a coincidence.
maccard 10y ago
It's fairly regular in my field (game dev) to put some debugging/instrumentation code in and only enable it for one frame after a key is pressed.

Zenst 10y ago

IBM spent a humongous amount of man hours upon the running man in smit under AIX, many of those consumed with making sure it ran correctly on all systems of various speeds without the animations going crazy. Alas I don't have exact man hours, but that was what one of the engineers told me a nearly 2 decades ago now. Hopefully somebody else has more detail upon this as one of the earliest examples of progress animations that still runs today that I'm aware of. I still hark back to the days of the C64 and the likes in which had tape storage and was common to have a game as a loading screen to play. Was a small program and used to give the user something to do whilst they waited 20 minutes for the program to load. Many also rewrote the cassette storage code for faster storage/loading and would often be a case of loading that program with the small game like space invaders that you could play whilst the main game loaded utilising the quicker tape handling code.

krylon 10y ago
Broken Sword let you play Breakout during the installation; it was such fun (I had not played Breakout in a long time at the point) I was almost sad when the installation was finished. ;-) I have often wondered since why this was not a more popular way to deal with long running installers.
- royjacobs 10y ago
  Having minigames during loading or installation was actually patented by Namco for Ridge Racer, I believe. I'm not quite sure about the details since I seem to recall things like invade-a-load on my Commodore 64 at least a decade earlier, but there you go.
  - Cpoll 10y ago
    Expired in 2015 :) When I was younger, it seemed so obvious to add a minigame to a long loading screen, I had assumed that there were technical reasons for not doing it.
- aerique 10y ago
  I think it's because Namco had a patent on games in loading screens from 1995 to 2015: http://kotaku.com/the-patent-on-loading-screen-mini-games-is-about-to-exp-1744705351 http://kotaku.com/the-patent-on-loading-screen-mini-games-is...

peckrob 10y ago

This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner in it when you ran it with verbose options. At the time I was on a slow dialup connection as I was on break from school, and something weird would happen. Every time I ran the script to test it, my Internet connection would become nearly unusable. But as soon as the script finished, it would suddenly start working again. As you can imagine, this was very confusing since the script was running entirely on a remote system. What the hell is going on? This stumped me for an hour or so until I ran it without the verbose option ... and it didn't happen. Then I finally realized what was happening: I was refreshing the spinner on EACH ROW and remote machine was going through the rows so quickly that sending refreshes for the spinner saturated my tiny dial-up connection. Changing this to only update once a second fixed it entirely. And that's how I DoS'd myself with a spinner.

kelvin0 10y ago
Nice foot gun story. If you had a T1 at the time, you would never had noticed such a pitfall.
- peckrob 10y ago
  Pretty much, yeah. I never noticed it on campus because I was sitting on a 10 megabit connection. That added an extra dimension to the confusion because I was sure this never happened when I was on campus, only when I was sitting 300 miles away. It was still happening if I had bothered to look at the network stats, just not enough to entirely saturate the connection.
- agumonkey 10y ago
  I often advise to write code on "obsolete" tech. It makes every bit of cruft obvious.
  - 10y ago

tmsldd 10y ago

Minimizing the installation window would prevent the paint event and your installation would finish quickly...