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.
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.
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.
That’s the average worst case user.
This also means I notice massively if an app has hardcoded timeouts, or loads massive amounts of data.
On the same project I discovered that "System.Envireonment.NewLine" was a relatively expensive call on c#, caching the result of that property was another 50% cut to CPU.
For Android Application development, we used to connect devices to computer via usb and would see the device's log in logcat tool (Android Studio). The device, in general, spawns lots of logcat messages during a debugging session and would eats up CPU.
The case is still worse that the tool stucks when device is connected over wifi (wifi-adb) as the data transfer is little lower in wifi than usb.
P.S. I have sped up my shit. That process originally took days, now it takes an hour.
That's a perfect name, I love it.
[0] http://www.startrek.com/database_article/heisenberg-compensa...
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.
I have often wondered since why this was not a more popular way to deal with long running installers.
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.
I don't know enough about patents to say if there was a reason the prior art didn't apply, but I know that Namco was fairly protective of it and it was somewhat limiting for people working in the game industry.
Although, loading screens are less common now than they were back then, and I think that would still be case even if such a thing were never patented.
If anyone knows where I can get those animation frames, I'd like them for a personal project as a "running" indicator.
(And by normally I mean, as booted from a LiveCD.)
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.
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.
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/ms6...
The "built in text edit control" IS a native text field already.
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).
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.
Windows allows this. In a parent comment I posted a link to the API docs. All Windows requires is a window to hold the caret, it doesn't care what kind of window it is.
Probably because they are using electron.
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.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.
Lodash has a debounce function which is useful to throttle UI features hooked to incoming data. 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.
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.
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)
Reported almost 3 years ago and still not fixed...
(This is a perfect example of what I've been increasingly convinced of lately: that the whole "paint"/"compositing" distinction hurts the Web…)
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/ms6...
My favorite issues was that on one OS (windows I think) a panel would only be visible if pixel 0,0 was on the screen and nothing was on top of it. The panel could be 99% visible but not be shown at all if the upper left corner was under another panel.
Only? It shouldn't be necessary to layout the entire window to redraw a cursor.
Also, if it did update every 500ms:
- it still would use about half a percent of CPU. On a machine whose CPU easily is >200 times as fast as those powering the first GUIs (and those _could_ blink the caret at less than 100% CPU) and that has a powerful GPU, that's bad (yes, those old-hat systems had far fewer pixels to update, but that's not a good excuse)
- implementing smoother blinking (rendering various shades of gray in-between) would mean going back to 13% CPU.
I would try and hack this by layering an empty textfield on top of the content, just to get a blinking caret. Or is it too hard to make that the right size and position it correctly?
Can you explain in simple terms why this is the case? Why on earth not?
Does that answer your question? :)
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.