May 27, 2019
On Mon, May 27, 2019 at 1:05 AM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote:
> > How does the API's threadsafety mechanisms work? How does it scale to my 64-core PC? How does it schedule the work? etc...
>
> Ah yes, if you don't run the GUI on a single thread then you have a lot to take into account.

Computers haven't had only one thread for almost 20 years. Even mobile
phones have 8 cores!
This leads me back to my original proposition.

May 27, 2019
On Monday, 27 May 2019 at 20:14:26 UTC, Manu wrote:
> Computers haven't had only one thread for almost 20 years. Even mobile
> phones have 8 cores!
> This leads me back to my original proposition.

If Robert is aiming for embedded and server rendering then he probably wants a simple structure with limited multi-threading.

*shrug*

May 27, 2019
On Mon, May 27, 2019 at 2:00 PM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 27 May 2019 at 20:14:26 UTC, Manu wrote:
> > Computers haven't had only one thread for almost 20 years. Even
> > mobile
> > phones have 8 cores!
> > This leads me back to my original proposition.
>
> If Robert is aiming for embedded and server rendering then he probably wants a simple structure with limited multi-threading.

Huh? Servers take loads-of-cores as far as you possibly can! Zen2 parts announced the other day, they'll give our servers something like 256 threads!

Even embedded parts have many cores; look at every mobile processor.
But here's the best part; if you design your software to run well on
computers... it does!
Multi-core focused software tends to perform better on single-core
setups than software that was written for single-core in my
experience.
My most surprising example was when we rebooted our engine in 2005 for
XBox360 and PS3 because we needed to fill 6-8 cores with work and our
PS2 era architecture did not do that effectively. At the time, we
worried about how the super-scalar choices we were making would affect
Gamecube which still had just one core. It was a minor platform so we
thought we'd just wear the loss to minimise tech baggage... boy were
we wrong! Right out of the gate, our scalability-focused architecture
ran better on the single-core machines than the previous highly mature
code that had received years of optimisation. It looked like there
were more moving parts in the architecture, but it still ran
meaningfully faster.
The key reason was proper partitioning of work. If you write a
single-threaded app, you are almost 100% guaranteed to blatantly
disregard software engineering in favour of a laser focus on your API
and user experience, and you will write bad software as a result.
Every time.

May 28, 2019
On Monday, 27 May 2019 at 21:21:35 UTC, Manu wrote:
> Huh? Servers take loads-of-cores as far as you possibly can!

Yes, but you might want to limit a single client to a process and limit the thread count, for isolation and simple load balancing. But I am not sure what the use scenario is...

> Even embedded parts have many cores; look at every mobile processor.

Usually limited. Correctness is more difficult to prove with high levels of parallelism... And you can use FPGA...

> Multi-core focused software tends to perform better on single-core
> setups than software that was written for single-core in my
> experience.

That is odd. Parallell algorithms usually comes with overhead.

At the time,
> we
> worried about how the super-scalar choices we were making would affect
> Gamecube which still had just one core.

You meant parallell? (super scalar just means that a single core has multiple execution units, a single core can schedule multiple instructions at the same time)

> If you write a
> single-threaded app, you are almost 100% guaranteed to blatantly
> disregard software engineering in favour of a laser focus on your API
> and user experience, and you will write bad software as a result.

Well, if you need more than a single thread to update a gui (sans rendering) then you've picked the wrong layout strategy in my opinion.

I dont want the gui to suck up a lot of cpu time and polute the caches.

And yes I think layout engine API as well as styling are very important to do well, even if it incurs overhead.

I'd rather have simple layout if that is the bottle neck...

Layout engine design a styling engine design is really the biggest challenge. You cannot design the architecture before those two are known.  Also embedded have fixed screen dimensions... No need for real time resizing...

What is missing is a good detailed description of primary use scenarios. Without that no rational design decisions can be made.

That is software engineering 101.

Without that we will just talk past eachother making different assumptions.

What is certain is that the long page browser layout engine isn't very well suited for fixed dimensions...


May 28, 2019
On 2019-05-27 20:56:15 +0000, Ola Fosheim Grøstad said:

> If Robert is aiming for embedded and server rendering then he probably wants a simple structure with limited multi-threading.

We are considering MT. A GUI should never stuck, as a user I'm the most important part and my time is most valuable. So, an application should never ever slow me down.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

May 28, 2019
On Tuesday, 28 May 2019 at 06:37:47 UTC, Robert M. Münch wrote:
> We are considering MT. A GUI should never stuck, as a user I'm the most important part and my time is most valuable. So, an application should never ever slow me down.

Just be aware that implementing a multithreaded constraint solver is something that you will have to spend a lot of time on.

Rendering is easy to do in parallel.

May 28, 2019
On Tuesday, 28 May 2019 at 05:52:23 UTC, Ola Fosheim Grøstad wrote:
> Also embedded have fixed screen dimensions... No need for real time resizing...

Every element that can include other elements and can be resized behaves *the same* as the resizable main window. Examples: floating window, docked window, SplitView, table's column.

You can change the element dimensions programmatically - directly or via styling, maybe with transition effects. They can be dependent on each other or on the parent/sibling dimensions. In all these cases, the computations layout engine performs are the same.

> What is certain is that the long page browser layout engine isn't very well suited for fixed dimensions...

Why fixed screen device cannot have scrolling? Logic?
May 28, 2019
On Tuesday, 28 May 2019 at 07:33:39 UTC, dayllenger wrote:
> You can change the element dimensions programmatically - directly or via styling, maybe with transition effects. They can be dependent on each other or on the parent/sibling dimensions. In all these cases, the computations layout engine performs are the same.

You can, but why should you?   We need to think about this in terms of usability requirements and use scenario constraints, not in terms of what is possible programatically.

1. There is no need to recompute the layout 60 times per second in this use case. Maybe it is better to have 2 types of layout: one static and one dynamic.

2. On some displays any type of motion looks really bad because the screen refresh is slow (high latency). E.g. electronic ink displays.

> Why fixed screen device cannot have scrolling? Logic?

You can have scrolling, but it makes for very poor usability.

If you create a UI for controlling big dangerous equipment then you don't want the information to be off-screen.



May 28, 2019
On Tuesday, 28 May 2019 at 07:22:06 UTC, Ola Fosheim Grøstad wrote:
> Just be aware that implementing a multithreaded constraint solver is something that you will have to spend a lot of time on.


Btw, Apple is using a version of Cassowary. There are many implementations available:

http://overconstrained.io/


May 28, 2019
On 5/28/19 2:37 AM, Robert M. Münch wrote:
> 
> We are considering MT. A GUI should never stuck, as a user I'm the most important part and my time is most valuable. So, an application should never ever slow me down.
> 

It's incredibly refreshing to hear a developer say that, instead of the usual, "As a *developer*, I'm the most important part and my time is most valuable. So, my users should just go buy faster hardware."