May 21, 2019
On 2019-05-21 17:29:51 +0000, Ola Fosheim Grøstad said:

> On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote:
>> Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 
>> 
> 
> That looks better :-)

:-) For a pixel perfect full responsive GUI I need to think about it a bit more. But that's not high priority at the moment.

> Just make sure that you pick an architecture that allows you to use spatial datastructures later on!

The nice thing about the design is, that the necessary parts are totally indepdent. For example changing the spatial index to an other approach just needed 5 lines of code change in the framework. The places where the different parts meet, are kept to an absolut minimum and the interfaces are as thin as possible.

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

May 21, 2019
On 2019-05-21 16:07:33 +0000, Basile B. said:

> What kind of layouting ? GTK-like ? DelphiVCL-like ? Flex-like ?

Flex-Box like.

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

May 21, 2019
On Tuesday, 21 May 2019 at 18:08:52 UTC, Robert M. Münch wrote:
> :-) For a pixel perfect full responsive GUI I need to think about it a bit more. But that's not high priority at the moment.

Right, there is no point in making that part too complicated early on because you may find that you want to enable user interface elements that requires something completely different later on!

> The nice thing about the design is, that the necessary parts are totally indepdent. For example changing the spatial index to an other approach just needed 5 lines of code change in the framework. The places where the different parts meet, are kept to an absolut minimum and the interfaces are as thin as possible.

That's what I like to hear. So now you can focus on usability both for programmers and end users without being too concerned with the geometric details.



May 21, 2019
On 2019-05-21 16:51:43 +0000, Manu said:

>> The screencast shows a responsive 40x40 grid. Layouting the grid takes
>> about 230ms, drawing it about 10ms.
> 
> O_o ... I feel like 230 *microseconds* feels about the right time, and
> ~100 microseconds for rendering.

I don't think that's fast enough :-)

>> So this gives us 36 FPS which is IMO pretty good for a desktop app target
> 
> Umm, no. I would expect 240fps is the modern MINIMUM for a desktop
> app, you can easily make it that fast.

;-) Well, they key is to layout & render only changes. A responsive grid is an evil test-case as this requires a full cylce on every frame.

> Incidentally, we have a multimedia library workgroup happening to
> build out a flexible and as-un-opinionated-as-we-can gfx and gui
> libraries which may serve a wider number of users than most existing
> libraries,

Ah, ok. Sounds interesting...

> perhaps you should join that effort, and leverage the perf
> experts we have? There's a channel #graphics on the dlang discord.

I will have a look... need to get discord up & running. Too many chat channels these days...

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

May 22, 2019
On 22/05/2019 7:51 AM, Robert M. Münch wrote:
>> perhaps you should join that effort, and leverage the perf
>> experts we have? There's a channel #graphics on the dlang discord.
> 
> I will have a look... need to get discord up & running. Too many chat channels these days...

Use the web client and come say hello in the mean time :)
May 22, 2019
On Tue, May 21, 2019 at 12:55 PM Robert M. Münch via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 2019-05-21 16:51:43 +0000, Manu said:
>
> >> The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms.
> >
> > O_o ... I feel like 230 *microseconds* feels about the right time, and ~100 microseconds for rendering.
>
> I don't think that's fast enough :-)

It probably is :P

> >> So this gives us 36 FPS which is IMO pretty good for a desktop app target
> >
> > Umm, no. I would expect 240fps is the modern MINIMUM for a desktop app, you can easily make it that fast.
>
> ;-) Well, they key is to layout & render only changes. A responsive grid is an evil test-case as this requires a full cylce on every frame.

The worst case defines your application performance, and grids are
pretty normal.
You can make a UI run realtime ;)
I mean, there are video games that render a complete screen full of
zillions of high-detail things every frame!

May 22, 2019
On Wednesday, 22 May 2019 at 17:01:39 UTC, Manu wrote:
> You can make a UI run realtime ;)
> I mean, there are video games that render a complete screen full of
> zillions of high-detail things every frame!

But you shouldn't design a UI framework like a game engine.

Especially not if you also want to run on embedded devices addressing pixels over I2C.
May 22, 2019
On Wed, May 22, 2019 at 10:20 AM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 22 May 2019 at 17:01:39 UTC, Manu wrote:
> > You can make a UI run realtime ;)
> > I mean, there are video games that render a complete screen
> > full of
> > zillions of high-detail things every frame!
>
> But you shouldn't design a UI framework like a game engine.
>
> Especially not if you also want to run on embedded devices addressing pixels over I2C.

I couldn't possibly agree less; I think cool kids would design
literally all computer software like a game engine, if they generally
cared about fluid experience, perf, and battery life.
This extends to server software in data-centers, even more so in that
case. People really should look at games for how to write good
software in general.

There's a reason games can simulate a rich world full of dynamic data and produce hundreds of frames a second, is because the industry has spent decades getting really good at software design and patterns that treat computers like computers with respect to perf.

May 22, 2019
On Wed, May 22, 2019 at 02:18:58PM -0700, Manu via Digitalmars-d-announce wrote:
> On Wed, May 22, 2019 at 10:20 AM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
[...]
> > But you shouldn't design a UI framework like a game engine.
> >
> > Especially not if you also want to run on embedded devices addressing pixels over I2C.
> 
> I couldn't possibly agree less; I think cool kids would design literally all computer software like a game engine, if they generally cared about fluid experience, perf, and battery life.
[...]

Wait, wha...?!  Write game-engine-like code if you care about *battery life*??  I mean... fluid experience, sure, perf, OK, but *battery life*?!  Unless I've been living in the wrong universe all this time, that's gotta be the most incredible statement ever.  I've yet to see a fluid, high-perf game engine *not* drain my battery like there's no tomorrow, and now you're telling me that I have to write code like a game engine in order to extend battery life?

I think I need to sit down.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
May 22, 2019
On Wednesday, 22 May 2019 at 21:18:58 UTC, Manu wrote:
> I couldn't possibly agree less; I think cool kids would design
> literally all computer software like a game engine, if they generally
> cared about fluid experience, perf, and battery life.

A game engine is designed for full redraw on every frame.

He said he wanted to draw pixel by pixel and only update pixels that change. I guess this would be useful on a slow I2C serial bus. It is also useful for X-Windows. Or any other scenario where you transmit graphics over a wire.

Games aren't really relevant in those two scenarios, but I don't know what the framework is aiming for either.

> There's a reason games can simulate a rich world full of dynamic data and produce hundreds of frames a second, is

Yes, it is because they cut corners and make good use of special cases... The cool kids in the demo-scene even more so. That does not make them good examples to follow for people who care about accuracy and correctness. But I don't know the goal for this GUI framework is.

So could you make good use of a GPU, even in the early stages in this case? Yes. If you keep it as a separate stage so that you have no dependencies to the object hierarchy. I would personally have done it in two passes for a prototype. Basically translating the object hierarchy into geometric data every frame then use a GPU to take that and push it to the screen. Not very efficient, perhaps, but good enough to get 60FPS with max flexibility.

Is that related to games, yes sure, or any other realt-time simulation software. So not really game specific.