Hi, we are currently build up our new technology stack and for this create a 2D GUI framework.

https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0 


The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms. The mouse clicks are handled via a reactive message stream and routed to all graphical objects that are hit using a spatial-index. The application code part is about 50 lines of code, the rest is handled by the framework.

With all this working now, we have all necessary building blocks working together.

Next steps are to create more widgets and add a visual style system. The widgets themself are style-free and wire-frame only for debugging purposes.

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

On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote:
> Hi, we are currently build up our new technology stack and for this create a 2D GUI framework.
>
> https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0
>
>
> The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms,

Interesting, is each cell a separate item then?

So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell?

That's a lot of work. Are you using some kind of iterative physics based approach since you use hundreds of thousands of computations per cell?

On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote:
> Hi, we are currently build up our new technology stack and for this create a 2D GUI framework.
>
> https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0
>
>
> The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms. The mouse clicks are handled via a reactive message stream and routed to all graphical objects that are hit using a spatial-index. The application code part is about 50 lines of code, the rest is handled by the framework.
>
> With all this working now, we have all necessary building blocks working together.
>
> Next steps are to create more widgets and add a visual style system. The widgets themself are style-free and wire-frame only for debugging purposes.

Thanks! Very interesting project!

On 2019-05-19 21:21:55 +0000, Ola Fosheim Grøstad said:

> Interesting, is each cell a separate item then?

Yes, it's organized like this:

root => grid => 1..X columns ==(each colum)==> 1..Y cells

> So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell? That's a lot of work.

I must be fair, and add some other measurement in between. This includes managing a 2D spatial index for hit testing too, not only layouting.

>  Are you using some kind of iterative physics based approach since you use hundreds of thousands of computations per cell?

It's like the browser's flex-box model.


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

On 2019-05-19 21:21:55 +0000, Ola Fosheim Grøstad said:

> Interesting, is each cell a separate item then?
> 
> So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell?
> 
> That's a lot of work.

Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 


I optimized the whole thing a bit, so now a complete screen with layouting, hittesting, drawing takes about 28ms, that's 8x faster than before. Drawing is still around 10ms, layouting around 16ms, spatial index handling 2ms.

So this gives us 36 FPS which is IMO pretty good for a desktop app target. There might be some 2-3ms speed-up still possible but not worth the effort yet.

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

On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote:
> On 2019-05-19 21:21:55 +0000, Ola Fosheim Grøstad said:
>
>> Interesting, is each cell a separate item then?
>> 
>> So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell?
>> 
>> That's a lot of work.
>
> Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0
>
>
> I optimized the whole thing a bit, so now a complete screen with layouting, hittesting, drawing takes about 28ms, that's 8x faster than before. Drawing is still around 10ms, layouting around 16ms, spatial index handling 2ms.
>
> So this gives us 36 FPS which is IMO pretty good for a desktop app target. There might be some 2-3ms speed-up still possible but not worth the effort yet.

openGL backend I presume ?

On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote:
> Hi, we are currently build up our new technology stack and for this create a 2D GUI framework.
>
> https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0
>
>
> The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms. The mouse clicks are handled via a reactive message stream and routed to all graphical objects that are hit using a spatial-index. The application code part is about 50 lines of code, the rest is handled by the framework.
>
> With all this working now, we have all necessary building blocks working together.
>
> Next steps are to create more widgets and add a visual style system. The widgets themself are style-free and wire-frame only for debugging purposes.

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

On Sun, May 19, 2019 at 2:05 PM Robert M. Münch via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> Hi, we are currently build up our new technology stack and for this create a 2D GUI framework.
>
> https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0
>
>
> 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.

> 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.

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, perhaps you should join that effort, and leverage the perf experts we have?

There's a channel #graphics on the dlang discord.

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 :-)

> So this gives us 36 FPS which is IMO pretty good for a desktop app target. There might be some 2-3ms speed-up still possible but not worth the effort yet.

That's true. High efficiency spatial datastructures are hard to refactor so better to keep it simple in the beginning. Leave yourself room to experiment with different class hierarchies etc.

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

Another option is to use 2 passes.

Pass 1: collects geometric information, could even use virtual function calls.

Pass 2: highly optimized algorithm for calculating layout plugin-style (meaning you can start with something simple and just replace it wholesale since it doesn't depend on the object hierarchies)

Then you can think more about usability and less about performance. Sure, there is a performance price, but flexibility is more important in the first iterations. KISS until the design is locked down FTW.

On 2019-05-21 15:57:20 +0000, Basile B. said:

> openGL backend I presume ?

No, CPU rendering to memory-buffer.

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