5 ms·

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs t

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

undefined_void 5y ago
yes
qbasic_forever 5y ago
There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.
modeless 5y ago
If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.
- raphlinus 5y ago
  I find your ideas intriguing and I wish to subscribe to your newsletter. More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease. If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.
  - ______-_-______ 5y ago
    By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?
    - raphlinus 5y ago
      At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.
      - ______-_-______ 5y ago
        I have no credible plan and I would need some mentoring before I could even be productive. Sounds like you probably want someone with more relevant experience.
  - modeless 5y ago
    I wouldn't start a browser from scratch, it's too big and compatibility is a never ending quagmire. I think it would be cool to do a new portable app platform with bits and pieces of the web platform like WebGPU, combined with new stuff, kind of like how deno is using web APIs outside the web. Maybe combined with the ideas from the redbean server.
- Narishma 5y ago
  Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.
  - modeless 5y ago
    Writing a new browser would take many years and those systems would be obsolete :) But there's also an intention to produce a more compatible restricted subset of WebGPU at some point.
- astrange 5y ago
  GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.
  - modeless 5y ago
    https://sluglibrary.com/ https://sluglibrary.com/ says otherwise
    - astrange 5y ago
      Games aren't a good system performance workload because nobody cares if they scale down, only if they scale up.
      - modeless 5y ago
        Nothing constrains Slug to games. Adobe has licensed it for example.
        astrange 5y ago
        Eh, that's a good sign for Unicode support but otherwise it's pretty similar. Photoshop and games are both foreground apps, Acrobat less so, but browsers and system UI are closer to utilities you don't want using all your resources. The perf issues are mainly latency (CPU<>GPU communication) and power (turning the GPU on) on discrete GPUs, integrated/mobile GPUs are better off there but memory use can be a problem. Other issues: - skipping the DOM and system font API loses you copy-paste, translation, and screen readers - subpixel AA and hinting usually get lost, although they're doable - it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window
        modeless 5y ago
        > skipping the DOM and system font API loses you copy-paste, translation, and screen readers Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that. > subpixel AA and hinting usually get lost, although they're doable Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only. > it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window This can probably be minimized with some effort. To the extent that it can't be identical, web content is so obviously not native already that I think it doesn't matter.
- nyanpasu64 5y ago
  If I developed a new browser today, my baseline graphics abstraction would be CPU-side pixel buffers manipulated by compiled (WASM/native) code. CPU rendering works equally well on past, present, and future CPUs, works with working and buggy and missing GPU drivers, works on every computer made in the last few decades, will never be obsoleted like Glide and DX7-9 and OpenGL, and is plenty fast enough outside of 4K or 144FPS rendering.
  - modeless 5y ago
    No need to develop a new browser, you can easily configure yours to disable GPU rendering. If you like things to be slow and inefficient. Personally I'm never buying any display under 1440p 120 Hz again and I prefer to run workloads where they're efficient, so I'll continue to use GPUs for graphics.

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

undefined_void 5y ago

yes

qbasic_forever 5y ago

There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.

modeless 5y ago

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

raphlinus 5y ago
I find your ideas intriguing and I wish to subscribe to your newsletter. More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease. If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.
- ______-_-______ 5y ago
  By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?
  - raphlinus 5y ago
    At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.
    - ______-_-______ 5y ago
      I have no credible plan and I would need some mentoring before I could even be productive. Sounds like you probably want someone with more relevant experience.
- modeless 5y ago
  I wouldn't start a browser from scratch, it's too big and compatibility is a never ending quagmire. I think it would be cool to do a new portable app platform with bits and pieces of the web platform like WebGPU, combined with new stuff, kind of like how deno is using web APIs outside the web. Maybe combined with the ideas from the redbean server.
Narishma 5y ago
Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.
- modeless 5y ago
  Writing a new browser would take many years and those systems would be obsolete :) But there's also an intention to produce a more compatible restricted subset of WebGPU at some point.
astrange 5y ago
GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.
- modeless 5y ago
  https://sluglibrary.com/ https://sluglibrary.com/ says otherwise
  - astrange 5y ago
    Games aren't a good system performance workload because nobody cares if they scale down, only if they scale up.
    - modeless 5y ago
      Nothing constrains Slug to games. Adobe has licensed it for example.
      - astrange 5y ago
        Eh, that's a good sign for Unicode support but otherwise it's pretty similar. Photoshop and games are both foreground apps, Acrobat less so, but browsers and system UI are closer to utilities you don't want using all your resources. The perf issues are mainly latency (CPU<>GPU communication) and power (turning the GPU on) on discrete GPUs, integrated/mobile GPUs are better off there but memory use can be a problem. Other issues: - skipping the DOM and system font API loses you copy-paste, translation, and screen readers - subpixel AA and hinting usually get lost, although they're doable - it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window
        modeless 5y ago
        > skipping the DOM and system font API loses you copy-paste, translation, and screen readers Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that. > subpixel AA and hinting usually get lost, although they're doable Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only. > it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window This can probably be minimized with some effort. To the extent that it can't be identical, web content is so obviously not native already that I think it doesn't matter.
nyanpasu64 5y ago
If I developed a new browser today, my baseline graphics abstraction would be CPU-side pixel buffers manipulated by compiled (WASM/native) code. CPU rendering works equally well on past, present, and future CPUs, works with working and buggy and missing GPU drivers, works on every computer made in the last few decades, will never be obsoleted like Glide and DX7-9 and OpenGL, and is plenty fast enough outside of 4K or 144FPS rendering.
- modeless 5y ago
  No need to develop a new browser, you can easily configure yours to disable GPU rendering. If you like things to be slow and inefficient. Personally I'm never buying any display under 1440p 120 Hz again and I prefer to run workloads where they're efficient, so I'll continue to use GPUs for graphics.