6 ms·

In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-bas

In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time. Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects. edit to add: and switching to DOM rendering Rik Arends[3] was one of the Ajax.org folks and he's been working on a WebGL-based code environment called Makepad[4], which is entirely built in Rust and has its own UI toolkit. He's complained a lot about how difficult it is to make a performant JS-based editing environment. My point in all of this is just that there are absolutely tradeoffs in performance, accessibility, ease-of-development, internationalization, and likely other aspects. If raw performance is what you're going for, it's hard to beat just drawing on a canvas or using WebGL. Google Docs needs to worry about all of that other stuff, too, so I'll be interested to see how this shapes up. [1]: https://en.wikipedia.org/wiki/Mozilla_Skywriter https://en.wikipedia.org/wiki/Mozilla_Skywriter [2]: https://en.wikipedia.org/wiki/Ace_(editor) https://en.wikipedia.org/wiki/Ace_(editor) [3]: https://twitter.com/rikarends https://twitter.com/rikarends [4]: https://makepad.dev https://makepad.dev

skyde 5y ago
Can someone explain why https://makepad.dev/ https://makepad.dev/ is extremely slow and "unusable" on Microsoft Edge browser but run smoothly on Chrome? Is it because of bad WebGL perf on JavasSript perf in general?
- ComputerGuru 5y ago
  Edge or Edgium?
- tyingq 5y ago
  Another possibility is code that acts differently depending on user-agent.
  - rikarendsmp 5y ago
    It most definitely does not.
- yonl 5y ago
  For me, it's not very fast in chrome.
  - ehsankia 5y ago
    Can you give a bit more flavor to "not very fast"? I'm on a measly chromebook and scrolling, selecting text, expanding directories, everything is smooth and high framerate. Is there a specific operation that is not fast? Opening it for the first time took a few seconds but afterwards it was pretty buttery.
    - rikarendsmp 5y ago
      Makepad kinda has a minimum GPU spec. It's aging-out for the people who don't have this, but some people still don't have gpu's that can bitblit their screen with a solid color.
  - fulafel 5y ago
    You might be getting the software rendering webgl implementation if there are GPU driver problems (https://blog.chromium.org/2016/06/universal-rendering-with-swiftshader.html https://blog.chromium.org/2016/06/universal-rendering-with-s...). (Of course in principle you don't need hardware acceleration to make this kind of thing run fast...)
- slaymaker1907 5y ago
  Did you try using dev/canary Edge? It should pretty much be the same rendering engine and JS engine as Chrome. Definitely report this to the Edge team if you have the time (very easy to do from the dev version of Edge). In my experience, they are very responsive to bug reports and feature suggestions.
  - rikarendsmp 5y ago
    Back in the day i made it work on Edge on an xbox. This was microsofts browser +JS engine. Nowadays its just chrome though. If it has problems, i'd be highly surprised.
- rikarendsmp 5y ago
  I tried for it not to be, however there is no technically specific reason no.
incrudible 5y ago
> ... it's hard to beat just drawing on a canvas or using WebGL. Both of these APIs perform quite poorly for what they're doing. To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.
- blacktriangle 5y ago
  They don't need to be better than native, they just need to be better than the DOM plus have the advantages of web-based distribution.
- axguscbklp 5y ago
  >Both of these APIs perform quite poorly for what they're doing. When it comes to Canvas, do you mean that it actually performs poorly when putting pixels on the screen using putImageData, or do you mean that it does that fine but it performs poorly when it comes to drawing vector graphics? In either case, do you know why it performs poorly? Personally, I would be happy if Canvas just let you put raw pixel data on the screen and did that as well as possible. I have never felt any need for its vector graphics features. To me, they seem too high-level for what Canvas is supposed to be. But I guess things are different when it comes to using the graphics card, since from what I understand it is actually optimized for drawing polygons.
  - fock 5y ago
    I think this is a problem of the mainstream conception seeing the future browser mainly as a monopolized, walled garden (compared to GNU/Linux, which nowadays would do everything one wanted from a computer and more) with the canvas being a kind of framebuffer. Back when I first read about the canvas, iirc there was no fancy CSS, no fancy custom elements and making a simple doodle-element or the famous doodle-jump as a webapp was ... - well, I guess there was flash. So if you think of HTML and DOM as a GUI toolkit, it filled an important void (and continues to do so) but nowadays noone wants to use (standardized) HTML anymore, so... If you look into tk (or nowadays tkinter) you basically see the same with the Canvas-class (I think you can't draw anything custom at all in tk easily)!
jd3 5y ago
It's funny — Google's approach here reminds me of the Netscape/Mozilla XUL tree[0] element. For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM. I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products. It's interesting that both Google's canvas bet (Flutter, Docs, etc.) and the Mozilla XUL tree are basically trying to solve a nearly identical problem (DOM nodes are expensive and DOM manipulation is slow) ~20-25 years apart. [0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/tree https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... [1]: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGfWH5Gn4RMKKFPaPrGpZo/edit https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf... [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 [3]: chrome://browser/content/places/places.xhtml [4]: https://www.thunderbird.net/ https://www.thunderbird.net/ [5]: https://www.seamonkey-project.org/ https://www.seamonkey-project.org/
- jd3 5y ago
  tangential but amusing — the old chrome://global/content/config.{xul/xhtml} used a XUL tree and rendered 0 DOM nodes to display its treechildren whereas the new about:config renders upwards of 4500 <tr> DOM nodes by default ignoring the fact that you can no longer sort by specific columns (name, status, type, value, etc), you can really feel how slow the new implementation is if you click the "Show Only Modified Preferences" button — the DOM update feels incredibly sluggish whereas both searching and sorting columns in the old xul tree always felt snappy and instantaneous https://imgur.com/a/abhYoW8 https://imgur.com/a/abhYoW8
  - lol768 5y ago
    Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".
IshKebab 5y ago
Try holding down Alt on https://makepad.dev/ https://makepad.dev/ Such a cool feature that you can't really do with DOM based solutions (VSCode could never do this).
- rikarendsmp 5y ago
  It may sound stupid, but this was the feature i tried to add to ACE and i couldn't. And i spent the last decade trying to invent a drawing API that would let me do this effect.
- Gaelan 5y ago
  Would anyone mind explaining/screenshotting what it does, for the benefit of those of us on phones?
  - igorbark 5y ago
    it basically folds (hides) the implementation code of every method in the file, giving an API-like view, but with a smooth animation shrinking the text instead of instantly disappearing it
- jamesfmilne 5y ago
  Nnnnnnng, this is awesome, and annoying because it's so good. Imagine coupling it with the mouse wheel to zoom in/out. I'd love to have this in MacVim/gvim somehow.

skyde 5y ago

Can someone explain why https://makepad.dev/ https://makepad.dev/ is extremely slow and "unusable" on Microsoft Edge browser but run smoothly on Chrome? Is it because of bad WebGL perf on JavasSript perf in general?

ComputerGuru 5y ago
Edge or Edgium?
tyingq 5y ago
Another possibility is code that acts differently depending on user-agent.
- rikarendsmp 5y ago
  It most definitely does not.
yonl 5y ago
For me, it's not very fast in chrome.
- ehsankia 5y ago
  Can you give a bit more flavor to "not very fast"? I'm on a measly chromebook and scrolling, selecting text, expanding directories, everything is smooth and high framerate. Is there a specific operation that is not fast? Opening it for the first time took a few seconds but afterwards it was pretty buttery.
  - rikarendsmp 5y ago
    Makepad kinda has a minimum GPU spec. It's aging-out for the people who don't have this, but some people still don't have gpu's that can bitblit their screen with a solid color.
- fulafel 5y ago
  You might be getting the software rendering webgl implementation if there are GPU driver problems (https://blog.chromium.org/2016/06/universal-rendering-with-swiftshader.html https://blog.chromium.org/2016/06/universal-rendering-with-s...). (Of course in principle you don't need hardware acceleration to make this kind of thing run fast...)
slaymaker1907 5y ago
Did you try using dev/canary Edge? It should pretty much be the same rendering engine and JS engine as Chrome. Definitely report this to the Edge team if you have the time (very easy to do from the dev version of Edge). In my experience, they are very responsive to bug reports and feature suggestions.
- rikarendsmp 5y ago
  Back in the day i made it work on Edge on an xbox. This was microsofts browser +JS engine. Nowadays its just chrome though. If it has problems, i'd be highly surprised.
rikarendsmp 5y ago
I tried for it not to be, however there is no technically specific reason no.

incrudible 5y ago

> ... it's hard to beat just drawing on a canvas or using WebGL. Both of these APIs perform quite poorly for what they're doing. To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.

blacktriangle 5y ago
They don't need to be better than native, they just need to be better than the DOM plus have the advantages of web-based distribution.
axguscbklp 5y ago
>Both of these APIs perform quite poorly for what they're doing. When it comes to Canvas, do you mean that it actually performs poorly when putting pixels on the screen using putImageData, or do you mean that it does that fine but it performs poorly when it comes to drawing vector graphics? In either case, do you know why it performs poorly? Personally, I would be happy if Canvas just let you put raw pixel data on the screen and did that as well as possible. I have never felt any need for its vector graphics features. To me, they seem too high-level for what Canvas is supposed to be. But I guess things are different when it comes to using the graphics card, since from what I understand it is actually optimized for drawing polygons.
- fock 5y ago
  I think this is a problem of the mainstream conception seeing the future browser mainly as a monopolized, walled garden (compared to GNU/Linux, which nowadays would do everything one wanted from a computer and more) with the canvas being a kind of framebuffer. Back when I first read about the canvas, iirc there was no fancy CSS, no fancy custom elements and making a simple doodle-element or the famous doodle-jump as a webapp was ... - well, I guess there was flash. So if you think of HTML and DOM as a GUI toolkit, it filled an important void (and continues to do so) but nowadays noone wants to use (standardized) HTML anymore, so... If you look into tk (or nowadays tkinter) you basically see the same with the Canvas-class (I think you can't draw anything custom at all in tk easily)!

jd3 5y ago

It's funny — Google's approach here reminds me of the Netscape/Mozilla XUL tree[0] element. For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM. I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products. It's interesting that both Google's canvas bet (Flutter, Docs, etc.) and the Mozilla XUL tree are basically trying to solve a nearly identical problem (DOM nodes are expensive and DOM manipulation is slow) ~20-25 years apart. [0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/tree https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... [1]: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGfWH5Gn4RMKKFPaPrGpZo/edit https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf... [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 [3]: chrome://browser/content/places/places.xhtml [4]: https://www.thunderbird.net/ https://www.thunderbird.net/ [5]: https://www.seamonkey-project.org/ https://www.seamonkey-project.org/

jd3 5y ago
tangential but amusing — the old chrome://global/content/config.{xul/xhtml} used a XUL tree and rendered 0 DOM nodes to display its treechildren whereas the new about:config renders upwards of 4500 <tr> DOM nodes by default ignoring the fact that you can no longer sort by specific columns (name, status, type, value, etc), you can really feel how slow the new implementation is if you click the "Show Only Modified Preferences" button — the DOM update feels incredibly sluggish whereas both searching and sorting columns in the old xul tree always felt snappy and instantaneous https://imgur.com/a/abhYoW8 https://imgur.com/a/abhYoW8
- lol768 5y ago
  Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".

IshKebab 5y ago

Try holding down Alt on https://makepad.dev/ https://makepad.dev/ Such a cool feature that you can't really do with DOM based solutions (VSCode could never do this).

rikarendsmp 5y ago
It may sound stupid, but this was the feature i tried to add to ACE and i couldn't. And i spent the last decade trying to invent a drawing API that would let me do this effect.
Gaelan 5y ago
Would anyone mind explaining/screenshotting what it does, for the benefit of those of us on phones?
- igorbark 5y ago
  it basically folds (hides) the implementation code of every method in the file, giving an API-like view, but with a smooth animation shrinking the text instead of instantly disappearing it
jamesfmilne 5y ago
Nnnnnnng, this is awesome, and annoying because it's so good. Imagine coupling it with the mouse wheel to zoom in/out. I'd love to have this in MacVim/gvim somehow.