W3C home > Mailing lists > Public > public-gpu@w3.org > July 2021

Re: As foundation for a large text editor web app, would WebGPU be quicker than the 2DContext in HTML Canvas?

From: Gregg Tavares <w3c@greggman.com>
Date: Fri, 16 Jul 2021 16:38:43 -0700
Message-ID: <CALouNzgPGCOiWe=6uLwwNyUtQz9gin1QbnnQXtJ+ia+62P7VPw@mail.gmail.com>
To: Myles Maxfield <mmaxfield@apple.com>
Cc: Justin Novosad <junov@google.com>, Kai Ninomiya <kainino@google.com>, Andrew Varga <grizzly33@gmail.com>, "Eamon O'Tuathail" <eamon.otuathail@gmail.com>, public-gpu <public-gpu@w3.org>
This is probably the wrong forum for this but

> When comparing against a 2D canvas implementation, there is no
architectural reason why a WebGL or WebGPU implementation must go faster
than a 2D canvas implementation for this kind of workload. Drawing 2D
stuff, like a text editor does, is exactly what 2D canvas was designed for.
If there is a workload that draws 2D stuff that executes significantly
faster in WebGL/WebGPU than in 2D canvas, that would be a bug in 2D canvas,
and should be fixed. As a browser engineer, I’d love details so I could
investigate these claims further

This is not true AFAIK. In WebGL or WebGPU you can optimize for your use
case in ways Canvas 2D never can. Just take the example of drawing a fixed
font ASCII terminal like a DOS command prompt or 80x50 glyphs (4000). In
WebGL/WebGPU I can fill out an arraybuffer with vertex positions and
texture coordinates and then submit that to the GPU. In Canvas 2D there is
no API that lets me do this. At best, I'd have to call
`drawImage(fontAtlas, glyphX, glyphY, glyphWidth, glyphHeight, dstX, dstY,
glyphWidth, glyphHeight)`. Even if behind the scenes the canvas
implementation magically filled out a buffer with the exact same data that
I could make in WebGL/WebGPU, the overhead of one function call per
character would alone be a 1.5x slowdown in some imaginary ideal
implementation. But, it's worse than that because Canvas2D is, under the
hood, a C/C++ API and there's a huge amount of overhead in the glue between
JS and C++ so every function call into the Canvas API is way slower than
just filling out some data in an arraybuffer.

Further, depending on what you're trying to do (the terminal example), in
WebGL/WebGPU you can create a shader who's input the screen memory itself
(the 80x50) saving you a huge overhead of translating that screen memory
into vertex coordinates.

In any case, I totally agree with Justin Novosad and Myles Maxfield that
repoing everything the browser is doing will be a huge task and probably
not as fast. Most people who find a speedup get one by seriously limiting
the features they support. For example using a fixed size font, of a single
size, and only ASCII. Add in full unicode support, any size text,
bidirectional text for right to left languages, emoji, styling, and input,
etc.... and it's an enormous task.

https://gankra.github.io/blah/text-hates-you/

https://lord.io/text-editing-hates-you-too/



On Fri, Jul 16, 2021 at 2:14 PM Myles Maxfield <mmaxfield@apple.com> wrote:

> I generally agree with Justin Novosad.
>
> When comparing against a DOM implementation, if you re-implemented in
> Javascript all of the things a browser does for text editing,
>
>    1. You’ll negate all of the potential performance improvements that
>    you thought you were getting. As you start out on the project, you will
>    appear to be getting huge performance benefits, but as you re-implement all
>    the things the browser does, your performance benefits will decrease to the
>    point of ceasing to exist. And, you’ll be writing JavaScript instead of
>    C++, so if you’re trying to do all the same things that a browser does
>    (which you should be), you won’t be able to go as fast.
>    2. You’re likely to not be as correct as the browser’s native text
>    editing code for all languages and scripts. Browsers have been in
>    development for decades, and have had decade’s worth of bug fixes. Getting
>    just static text to look correct is a challenging endeavor, and adding
>    editing behaviors on top of that significantly increases the scope of the
>    challenge.
>
>
> When comparing against a 2D canvas implementation, there is no
> architectural reason why a WebGL or WebGPU implementation must go faster
> than a 2D canvas implementation for this kind of workload. Drawing 2D
> stuff, like a text editor does, is exactly what 2D canvas was designed for.
> If there is a workload that draws 2D stuff that executes significantly
> faster in WebGL/WebGPU than in 2D canvas, that would be a bug in 2D canvas,
> and should be fixed. As a browser engineer, I’d love details so I could
> investigate these claims further.
>
> Text engines in browsers have been developed as general-purpose engines,
> designed to correctly and performantly display/edit any kind of text that
> appears on the internet. So, if that kind of workload is the kind of
> workload you are interested in, you’re going to have a tough time beating
> the browser by operating in Javascript inside the browser. However, if you
> have a domain-specific focus, like “I know all my users can clearly see the
> screen and they all only speak English and I’m going to force all the text
> to be displayed in a single font that doesn’t have any advanced layout
> features” then it seems clear that you could go faster than the browser.
> It’s just difficult to find a middle ground that is A) focused enough to be
> able to avoid enough work that the browser would be doing to improve
> performance beyond what the browser would be doing, and B) general enough
> that it’s useful for any reasonably-sized target audience.
>
> —Myles
>
> On Jul 16, 2021, at 9:59 AM, Justin Novosad <junov@google.com> wrote:
>
> Using canvas (2D or WebGL) for a text editor is a double-edged sword and I
> would not recommend it unless you are willing to invest a lot of effort
> into it.  The browser provides a lot of services that you get for free when
> you use HTML text.  Off the top of my head: text selection,
> accessibility support, page translation, text search (find in page), text
> shaping (ligatures, kerning, etc. see:
> https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html),
> bidirectional text rendering (to support right-to-left languages, such as
> Arabic), emojis.  There's also a bunch of complex and useful
> layout algorithms that the browser provides for positioning text in a
> document. Also the web crawlers that update search engine indexes won't see
> text that is in a canvas.  Browser extensions that help people with
> visual impairments (text magnification, contrast enhancement, color
> corrections for the color blind) are unlikely to work correctly.  Most of
> these issues have workarounds, and I am sure there are third party
> libraries to help with many of these, but it is still a large undertaking.
>
> Using a monospaced font helps avoid many of the complexities of text
> shaping. I think that may be what VSCode does. I guess it also depends on
> which of the above features you actually need to support.  For an editor
> you probably need at the very least to support text selection and text
> shaping.
>
>     -Justin
>
>
>
> On Wed, Jul 14, 2021 at 5:48 PM Kai Ninomiya <kainino@google.com> wrote:
>
>> +1. There are a number of examples out there that show using GL for
>> editor rendering can be extremely efficient. You may only need WebGL 1.0,
>> which has almost 100% reach; WebGL 2.0 or WebGPU will reach fewer users and
>> will probably provide only small benefits - unless you have specific
>> usecases for them (like if you have custom GPU text rendering algorithms or
>> something).
>>
>> -Kai (he/they)
>>
>>
>> On Wed, Jul 14, 2021 at 4:27 AM Andrew Varga <grizzly33@gmail.com> wrote:
>>
>>> I think yes, using WebGL or WebGPU would be much faster than using the
>>> canvas 2D context if it's optimized properly.
>>> A good example is makepad, which is open source, written in Rust and
>>> uses WebGL:
>>> https://github.com/makepad/makepad
>>> demo:
>>> https://makepad.dev/
>>>
>>> I suspect the difference between WebGL and WebGPU will not be
>>> significant, at least initially while WebGPU is still very new.
>>>
>>> On Wed, Jul 14, 2021 at 11:44 AM Eamon O'Tuathail <
>>> eamon.otuathail@gmail.com> wrote:
>>>
>>>> There are a number of ways of creating a text editor in a web app:
>>>> 1) using contenteditable
>>>> 2) using hidden text area (e.g. as seen with the Visual Studio Code's
>>>> Monaco text editor)
>>>>
>>>> https://www.mozzafiller.com/posts/how-does-monaco-editor-enable-textediting-on-a-web-page
>>>> 3) using HTML Canvas
>>>>
>>>> It seems for the larger text editor projects there is a trend to using
>>>> the HTML Canvas-approach, mostly using the 2D Context with some use of
>>>> WebGL. Here are some examples:
>>>>
>>>> Visual Studio Code's use of canvas for the integrated terminal is
>>>> described here:
>>>> https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer
>>>>
>>>> The Register here writes about Google moving its editors to Canvas:
>>>>
>>>> https://www.theregister.com/2021/05/13/google_warns_docs_rewrite_will/
>>>> Also Y Combinator has a very interesting thread discussing this:
>>>>   https://news.ycombinator.com/item?id=27129858
>>>>
>>>> In particular in the Y Combinator discussion I note Microsoft's Tyiar
>>>> states:
>>>> -----------------
>>>> "I wrote the terminal canvas renderers in VS Code that has been called
>>>> out a few times here. Initially I implemented a canvas renderer using just
>>>> a 2d context to draw many textures which sped things up "5 to 45 times"[1]
>>>> over the older DOM renderer.
>>>> Since then I moved onto a WebGL renderer[2] which was mostly a personal
>>>> project, it's basically the first canvas renderer but better in every way
>>>> since it works by organizing a typed array (very fast) and sending it to
>>>> the GPU in one go, as opposed to piece meal and having the browser do its
>>>> best to optimize/reduce calls. This was measured to improve performance by
>>>> up to 900% in some cases over the canvas renderer"
>>>> ----------------
>>>>
>>>> I suspect WebGPU will be faster than WebGL, so my question is, would a
>>>> text editor based on WebGPU be the absolutely fastest way of delivering a
>>>> modern text editing experience in a web browser/PWA app?
>>>>
>>>> Anyone got thoughts if this would be the case or real world (prototype)
>>>> experience of this?
>>>>
>>>> Eamon O'Tuathail
>>>> https://clipcode.net
>>>>
>>>
>
Received on Friday, 16 July 2021 23:39:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 16 July 2021 23:39:34 UTC