On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote:

They are the symptom that the underlying foundations are broken so we go the easy way: like we don't want to standardize the APIs on our OS so lets fire a browser and get standard APIs. Laziness over righteousness because computer power is cheap. And then we have all our critical internal data right there on the browser and ooops ... what can go wrong ?

On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:

Well, on a Mac I would just embed a WebView which already is ready in the OS UI framework. Electron allows you to execute native code I think ("Napi" or something?). A better approach is probably to use Chromium Embedded Framework v3, which supposedly is multithreaded.

Not that much of a performance bottle neck, unless you push a lot of data. I wouldn't use it for an audio/graphics editor. Memory usage is more of an issue though. Depends on the app, if it is a "clock" then it obviously is too much. If it is a full application then it is ok.

Primarily because it cuts down on developer time. It is easy to change and you can easily configure it for many configurations (e.g. easy to create a limited features version).

This trend will increase as web component repos become available. At some point it might become prohibitively expensive to develop complex user interfaces without web technology.

Right now, drag-and-drop is not as easily supported in browser UIs though. That is an argument for using native UI.

The problem now is that you have to support both Metal, OpenGL ES, and Direct X. Vulkan isn't well enough supported to be a convenient target.

History also tells us that hardware GPU abstractions tend to be weak and not last very long.

So you are still stuck with an abstraction layer like Skia. It is just too expensive to support all hardware yourself.

The game industry spends a lot of money supporting/testing various hardware drivers and working around bugs in said drivers/hardware.

At the end of the day, the user will be upset if the application crashes because of a vulkan-bug/hardware-bug. So in that context browser-overhead isn't all that bad.

It is not so much that I disagree, but the hard reality is that there are few attractive alternatives that are portable and also cuts down on developer time.

I would personally consider the options:

1. Rolling my own using Skia, especially if I only need mouse input and no keyboard.

2. CEF or WebView, just to get to a productive stage sooner. Assuming the UI is not pushing a large amount of data.

3. Qt/Gtk, but I think they come with a lot of baggage... so I personally don't find it more attractive than WebView for basic UIs. If you already know webtech it becomes even less attractive to learn a framework that is less flexible than a webview. I don't see a healthy future for Qt/Gtk, but webtech is there to stay.

Note: Many simple GUI toolkits are horribly inefficient as they let each object render themselves. An efficient GUI engine will have to replicate some of the browser complexity...

On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad wrote:

eh web drag and drop isn't half bad at all. Have you ever used it?

That doesn't make any sense.

On Tuesday, 1 June 2021 at 22:13:08 UTC, Adam D. Ruppe wrote:

My understanding is that dropping OS icons onto the web view is problematic, but maybe they have overcome this because of Chrome OS. No, I don't use it, except for file uploads.

Yes, it does. You get lots of graphic context switches and poor render-caching performance.

On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad wrote:

Thanks for the illustration on how you'll eventually proceed with it on the Mac side of things -I use iPhones since the 4 series but frankly I never developed on (or used for a significant time) a modern Mac.

It just came to mind the first time I installed and used a linux distro for a significant amount of time: it was Ubuntu in the 8~9 time-frame circa 2008~2009 (Jaunty Jackalope if memory serves), and coming from the Windows world, mainly on the Windows server platform which we usually (and thoroughly) optimized as workstations for our daily drivers (we can't even stood for a minute the amount of crap Microsoft dumped on its consumers OSs -even configuring them with the classical UI dumping animations and a zillion more things), the first thing I noticed and struck me was the responsiveness of the GUI: snappy as hell compared to the usual Windows 7 machines we dealt with at the time, and, I mean snappy as hell without customizing it disabling animations and the like, this was a responsive GUI out-of-the-box. It was on gnome 2 of course. The first time I saw gnome 3 was game over.

If we were on slashdot I would undoubtedly mark this as insightful.

IIRC openGL ES is for mobile not for desktop which needs plain openGL.

Of course individually supporting the three main APIs is a no-go, that's why I mentioned Vulkan, you say it is not mature, it will mature. To me Vulkan is like Wayland, there's no going back regardless whether you/we consider it has merits or not.

Indeed. But the market is so huge nowadays that the stakes are set higher. Or so I want to believe.

Indeed. But the game industry has totally different requirements/expectations for the hardware than we need to write a classical 2D GUI toolkit. They need APIs close to the hardware as possible and very often bypass everything in its path seeking 3D performance gains.

I guess Vulkan will have separate 2D/3D APIs like openGL so this will be no major concern giving the huge different code base size for each, but I am talking of pure guess, I will eventually read about it (at least) out of sheer curiosity.

Sad by true.

On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad wrote:

You have to subscribe to the particular content type so it doesn't always work but it is totally doable.

You can play with it using simpledisplay.d's drag and drop support.

Web drag and drop actually dates back to IE 5. It has been cleaned up a little since then and now prefers mime types to the type enum it used to do (though both still tend to work) but it isn't actually all that different.

no not really.

you'd have to be really incompetent to do it this wrong.

On Tuesday, 1 June 2021 at 22:50:49 UTC, someone wrote:

I am of a similar mindset as you, when I use Linux I tend to go minimal WM and setup.

It IS depressing how much resources editors use to reach the same fluidity as the editor I used on my Amiga in the 1980s (which used hardware registers for scrolling).

Yes, but WebGL is basically the same as ES, WebAssembly containers... D is supposed to support those?

I don't know. Hardware vendors are eager to reach market with new hardware and will most likely continue to ship buggy drivers for the bleeding edge hardware? But we can always hope. :)

Possibly. Yet, Skia release notes keep mentioning hardware related themes. I guess that could be your canary (wait until release notes no longer list hardware related issues).

There is no such thing as 2D/3D anymore AFAIK? Shaders are fairly generic.

But you have to support at least Metal and Vulkan, and possibly WebGL. Skia is less work.

On Tuesday, 1 June 2021 at 22:52:41 UTC, Adam D. Ruppe wrote:

If each widget imperatively draws itself you get graphic context switches every time you draw a different graphical element type.

If the render engine manages this, you have much more opportunity to group similar items. E.g. do all text of one font size in one GPU operation.

Then you also have the whole issue of backing store (caching) which cannot be done in an optimal fashion if the widget is in control.

On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad wrote:

Amiga's ? I did have them all (insert REALLY BIG SMILE here) !

I never used anything like Workbench anymore -when I say Ubuntu was snappy-as-hell and now remember what was like on the Amiga ... he. The Windows/Macs of the time seemed escaped out of prehistory those days. Even the Atari was far better. But you know what ? The IBM PC was the serious (laughing out loud) way to go. Sad. I did learn a lesson what market forces implied back at the time.

Didn't know. Thought it was a totally different story. Will look it up.

You have a point. The major bugs/annoyances are pretty soon ironed out for the Windows platform and never reach the nixes in parity. What we got was late, very late, often when two (or more) newer product generations already reached the market and all eyes are set on them and nobody cares supporting old hardware for 1% niche market share of the nixes. Quite understandable by the way. Nvidia/Broadcom being the worst when nix support comes to mind.

Huh

Bump.

Have you actually used it within D for anything remotely "serious" ? By serious I mean something not a casual/hobby project, something that you must rely on.

On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote:

When Skia release notes no longer mention changes due to hardware, then we can assume that the hardware abstraction is workable.

Not sure what you meant?

Of course not, D is a hobby and I consider D to be a work-in-progress.

Not sure how that relates to Skia? Skia is used in many products. If I was to use D for something serious, Skia would probably be the first thing I would consider...