5 ms·

One tradeoff of this is that the text smoothing is wrong (or at the very least, inconsistent with everything else on my computer, and does not respect my text s

One tradeoff of this is that the text smoothing is wrong (or at the very least, inconsistent with everything else on my computer, and does not respect my text smoothing settings). Personally I hope this "screw the OS, I'm rendering everything myself" strategy doesn't take off on account of that. It's like the web version of godawful cross platform Java apps from the 90's where they stick the Mac version's menubar inside the window because it looks right on their machine. I wonder if screenreaders work for reading and navigating this. EDIT: This comment comes across as totally negative, so I'd like to amend that I think there are good use-cases for it. Games or more visual things, sure, I don't care if the text isn't a pixel perfect match to everything else on my computer. But for things where reading or writing text is the primary purpose, having the same font face at the same size render differently from the rest of my computer is not something I want to see becoming common.

toyg 8y ago
> I hope this "screw the OS, I'm rendering everything myself" strategy doesn't take off on account of that. Dude, that battle was lost when Electron gained traction. I hate it with all my heart, but it's a sad reality.
- OskarS 8y ago
  Electron uses platform-native font rendering. It's just Chromium, and Chromium uses Uniscribe on Windows and CoreText on Mac. Compare Chrome on Windows and Mac, you'll see the difference in text rendering.
  - badsectoracula 8y ago
    Don't worry, people will simply start using Qt for WebAssembly with Electron to fix that issue.
  - jcelerier 8y ago
    uh... what ? the text on all electron apps looks like a blurred shit on my machine, and does not look at all like the text settings I apply.
    - deleted 8y ago
      [deleted]
  - toyg 8y ago
    Nobody cares. Developers use Electron because it gives consistent results across platforms, not because it looks native. If Chromium were to switch to a custom font renderer that looks exactly the same on all platforms, no developer using Electron would care - in fact, they would probably like it even more.
    - OskarS 8y ago
      I care! I care a lot! Good font rendering makes SO much difference in how stuff looks. No joke: font rendering is the number one reason I prefer the look of macOS over Windows (especially now since WSL exists). I realize I'm a weirdo font nerd and probably alone in that stance, but working with computers mean staring at text on a screen for hours and hours every day. It fucking better be rendered right.
- wlesieutre 8y ago
  Yes and no. My biggest gripe with Electron is that it tends to murder battery life. It still gives you native text rendering, and it gives you native menubars which have some options if not always as many as I'd like. At least there's not a fake menubar at the top of the window. There are other issues like contextual menus, in VS Code they're handled well and give you all the actions you'd expect. But in Slack it gives you the bare minimum OS included items and has their own "..." button on each message for things that ought to be in the contextual menu. It can also do multiple windows (again, see VS Code which is a good example), but Slack stuffs everything into one window (preferences overlay is a good example of what should be separate) because it's a much simpler wrapping of a webpage instead of being designed as a native app would be.
joezydeco 8y ago
Qt has the option to use an internal font renderer (FreeType, Harfbuzz, or ?), or rely on the host system for one. Unless Webassembly provides a common type rendering system or links to the Browser's host renderer, I'm not sure this can be fixed.
- RussianCow 8y ago
  WebAssembly is pretty orthogonal to rendering. The way this would be "fixed" is for WASM to have its own DOM APIs; then, WASM apps could render to the DOM like any other web app, so they would inherit all of its benefits (like native font rendering, OS-native input elements, accessibility, etc).
  - amelius 8y ago
    This would only work if DOM rendering is compatible with Qt's internal API. For example, if rendering in Qt is like drawing on a canvas, where you can later read out pixel-values, then this isn't going to work through the DOM. And it could require a lot of tricks to bring the two APIs together.
    - seba_dos1 8y ago
      It is "like drawing on a canvas", in some cases like QtQuick it's even working with OpenGL directly.
  - joezydeco 8y ago
    Yeah, Qt is not a DOM-based GUI. Both widgets and QML expect an underlying scene graph to be rendered out to a framebuffer or GL texture.
    - RussianCow 8y ago
      Sorry, yeah, I wasn't talking about Qt specifically, but WASM in general.
seba_dos1 8y ago
There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. Keep in mind though that editor demo is just one of already existing Qt's examples shown working inside the browser. I don't think any author of Qt based text editor will get excited that it will now be able to run inside the browser. However, there are plenty of other use cases that can actually get one very excited - for me personally the biggest deal is having Qt Quick working in the browser.
- Tehdasi 8y ago
  > There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. It's just pixels. Barring patents a wasm program can text any goddamn way it wants to.
  - seba_dos1 8y ago
    Of course. It just has no way to know how the system would do it, as the system can also do it any goddamn way its user wants it to.
- danShumway 8y ago
  > There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. Sure there is - put the text in the DOM. WebAssembly is just a runtime, it has nothing to do with whether you display your stuff in Canvas or via the DOM. If you were writing an app in Javascript, you wouldn't bundle a text engine into it and then bypass the DOM for all of your rendering. Why is WebAssembly different?
  - johncolanduoni 8y ago
    Then it wouldn't be "doing its rendering in WebAssembly". Even if you use that term very broadly, at the moment WebAssembly can't even interact with the DOM without going through JavaScript.

toyg 8y ago

> I hope this "screw the OS, I'm rendering everything myself" strategy doesn't take off on account of that. Dude, that battle was lost when Electron gained traction. I hate it with all my heart, but it's a sad reality.

OskarS 8y ago
Electron uses platform-native font rendering. It's just Chromium, and Chromium uses Uniscribe on Windows and CoreText on Mac. Compare Chrome on Windows and Mac, you'll see the difference in text rendering.
- badsectoracula 8y ago
  Don't worry, people will simply start using Qt for WebAssembly with Electron to fix that issue.
- jcelerier 8y ago
  uh... what ? the text on all electron apps looks like a blurred shit on my machine, and does not look at all like the text settings I apply.
  - deleted 8y ago
    [deleted]
- toyg 8y ago
  Nobody cares. Developers use Electron because it gives consistent results across platforms, not because it looks native. If Chromium were to switch to a custom font renderer that looks exactly the same on all platforms, no developer using Electron would care - in fact, they would probably like it even more.
  - OskarS 8y ago
    I care! I care a lot! Good font rendering makes SO much difference in how stuff looks. No joke: font rendering is the number one reason I prefer the look of macOS over Windows (especially now since WSL exists). I realize I'm a weirdo font nerd and probably alone in that stance, but working with computers mean staring at text on a screen for hours and hours every day. It fucking better be rendered right.
wlesieutre 8y ago
Yes and no. My biggest gripe with Electron is that it tends to murder battery life. It still gives you native text rendering, and it gives you native menubars which have some options if not always as many as I'd like. At least there's not a fake menubar at the top of the window. There are other issues like contextual menus, in VS Code they're handled well and give you all the actions you'd expect. But in Slack it gives you the bare minimum OS included items and has their own "..." button on each message for things that ought to be in the contextual menu. It can also do multiple windows (again, see VS Code which is a good example), but Slack stuffs everything into one window (preferences overlay is a good example of what should be separate) because it's a much simpler wrapping of a webpage instead of being designed as a native app would be.

joezydeco 8y ago

Qt has the option to use an internal font renderer (FreeType, Harfbuzz, or ?), or rely on the host system for one. Unless Webassembly provides a common type rendering system or links to the Browser's host renderer, I'm not sure this can be fixed.

RussianCow 8y ago
WebAssembly is pretty orthogonal to rendering. The way this would be "fixed" is for WASM to have its own DOM APIs; then, WASM apps could render to the DOM like any other web app, so they would inherit all of its benefits (like native font rendering, OS-native input elements, accessibility, etc).
- amelius 8y ago
  This would only work if DOM rendering is compatible with Qt's internal API. For example, if rendering in Qt is like drawing on a canvas, where you can later read out pixel-values, then this isn't going to work through the DOM. And it could require a lot of tricks to bring the two APIs together.
  - seba_dos1 8y ago
    It is "like drawing on a canvas", in some cases like QtQuick it's even working with OpenGL directly.
- joezydeco 8y ago
  Yeah, Qt is not a DOM-based GUI. Both widgets and QML expect an underlying scene graph to be rendered out to a framebuffer or GL texture.
  - RussianCow 8y ago
    Sorry, yeah, I wasn't talking about Qt specifically, but WASM in general.

seba_dos1 8y ago

There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. Keep in mind though that editor demo is just one of already existing Qt's examples shown working inside the browser. I don't think any author of Qt based text editor will get excited that it will now be able to run inside the browser. However, there are plenty of other use cases that can actually get one very excited - for me personally the biggest deal is having Qt Quick working in the browser.

Tehdasi 8y ago
> There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. It's just pixels. Barring patents a wasm program can text any goddamn way it wants to.
- seba_dos1 8y ago
  Of course. It just has no way to know how the system would do it, as the system can also do it any goddamn way its user wants it to.
danShumway 8y ago
> There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. Sure there is - put the text in the DOM. WebAssembly is just a runtime, it has nothing to do with whether you display your stuff in Canvas or via the DOM. If you were writing an app in Javascript, you wouldn't bundle a text engine into it and then bypass the DOM for all of your rendering. Why is WebAssembly different?
- johncolanduoni 8y ago
  Then it wouldn't be "doing its rendering in WebAssembly". Even if you use that term very broadly, at the moment WebAssembly can't even interact with the DOM without going through JavaScript.