On Tuesday, 23 June 2020 at 17:41:35 UTC, Robert M. Münch wrote:
On 2020-06-23 04:29:48 +, Виталий Фадеев said:
[...]
Not sure if this is a question or some project you do. However,
yes on all points for what we do.
[...]
Yes.
[...]
Well, beauty lies in the eye of the beholder.
On Tuesday, 23 June 2020 at 17:29:05 UTC, Robert M. Münch wrote:
On 2020-06-22 23:56:47 +, aberba said:
Will it be open source? Curious why its not hosted public
We will see...
The main point is, such a thing only lifts off if the quality
and out-of-the-box experience is high enough. I
On 2020-06-23 04:29:48 +, Виталий Фадеев said:
Width of the element can be set:
- by hand
--- fixed
- by automate
--- inherited from parent
--- from childs ( calculated max width )
--- generated by parent layout ( like a HBox, VBox, may be CircleLayout... )
and for each case:
- check min
On 2020-06-22 23:56:47 +, aberba said:
Will it be open source? Curious why its not hosted public
We will see...
The main point is, such a thing only lifts off if the quality and
out-of-the-box experience is high enough. I think we don't need an
other project, that might not get any
On Monday, 22 June 2020 at 16:43:12 UTC, Robert M. Münch wrote:
On 2019-05-19 21:01:33 +, Robert M. Münch said:
Hi, we are currently build up our new technology stack and for
this create a 2D GUI framework.
Some now teaser, again might not look like a lot had happend
but we move
On Monday, 22 June 2020 at 16:43:12 UTC, Robert M. Münch wrote:
On 2019-05-19 21:01:33 +, Robert M. Münch said:
[...]
Some now teaser, again might not look like a lot had happend
but we move forward, slow but steady:
https://www.dropbox.com/s/jjefzyneqnxr7pb/dgui_teaser-1.mp4
The
On 2019-05-19 21:01:33 +, Robert M. Münch said:
Hi, we are currently build up our new technology stack and for this
create a 2D GUI framework.
Some now teaser, again might not look like a lot had happend but we
move forward, slow but steady:
On 2019-05-19 21:01:33 +, Robert M. Münch said:
Hi, we are currently build up our new technology stack and for this
create a 2D GUI framework.
Hi, some more teaser showing a text-input field, with clipping,
scrolling, etc.:
On Wednesday, 29 May 2019 at 05:56:45 UTC, Nick Sabalausky
(Abscissa) wrote:
I think I still have a stack of floppies from an early version
of MS Visual C/C++. Plus similar floppy stacks from other 90's
compilers[1] But 31 install disks is quite impressive, I'm not
sure I can match that[2]. I
On 5/28/19 6:50 PM, Abdulhaq wrote:
On Tuesday, 28 May 2019 at 20:54:59 UTC, Robert M. Münch wrote:
.
The software we sell, would still fit on one floppy disk (if there are
still people knowing what it is). And I'm always saying: "Every good
software fits on one floppy-disk." Most people
On Tuesday, 28 May 2019 at 20:54:59 UTC, Robert M. Münch wrote:
.
The software we sell, would still fit on one floppy disk (if
there are still people knowing what it is). And I'm always
saying: "Every good software fits on one floppy-disk." Most
people can't believe that this is still
On 2019-05-28 07:22:06 +, Ola Fosheim Grøstad said:
Just be aware that implementing a multithreaded constraint solver is
something that you will have to spend a lot of time on.
I am... and I didn't meant that we want use MT everywhere.
MT is a tool, and after measuring and understanding
On 2019-05-28 15:54:14 +, Nick Sabalausky (Abscissa) said:
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."
In the mid 90s I
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
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:
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
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,
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
On 2019-05-27 20:56:15 +, 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
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...
On Mon, May 27, 2019 at 2:00 PM Ola Fosheim Grøstad via
Digitalmars-d-announce 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.
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
On Mon, May 27, 2019 at 1:05 AM Ola Fosheim Grøstad via
Digitalmars-d-announce 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
On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote:
Actually, I'm not really interested in rendering much. From the
original posts, the rendering time is most uninteresting cus
it's the end of the pipeline, the time that I was commenting on
at the start is the non-rendering time, which was
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.
On 2019-05-27 04:46:42 +, Nick Sabalausky (Abscissa) said:
Besides, from what Robert described, it sounds like he already has it
decoupled and modular enough that performance *can* likely be improved
later (probably by an order of magnitude) without too much disruption
to it's core
On Sun, May 26, 2019 at 10:25 PM Ola Fosheim Grøstad via
Digitalmars-d-announce wrote:
>
> On Monday, 27 May 2019 at 05:01:36 UTC, Manu wrote:
> > Performance is a symptom of architecture, and architecture *is*
> > the early stage.
>
> I expected that answer, but the renderer itself can just be a
On Monday, 27 May 2019 at 05:01:36 UTC, Manu wrote:
Performance is a symptom of architecture, and architecture *is*
the early stage.
I expected that answer, but the renderer itself can just be a
placeholder.
So yes, you need to think about where accelerating
datastructures/processes fit
On Monday, 27 May 2019 at 04:46:42 UTC, Nick Sabalausky
(Abscissa) wrote:
without too much disruption to it's core design. So, on that,
believe it or not, it sounds like we already agree. ;)
Alright! :-)
And I'll point out *again*, the only points I was trying to
make here were to dispel the
On Sun, May 26, 2019 at 8:50 PM Ola Fosheim Grøstad via
Digitalmars-d-announce wrote:
>
> On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky
> (Abscissa) wrote:
> > suggestion that Robert could get this going an order of
> > magnitude faster without too terribly much trouble. Luckily,
> >
On 5/26/19 11:46 PM, Ola Fosheim Grøstad wrote:
On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky (Abscissa) wrote:
suggestion that Robert could get this going an order of magnitude
faster without too terribly much trouble. Luckily, Ethan explained my
stance better than I was able to.
On 5/26/19 9:52 PM, Manu wrote:
Unity is perhaps the worst possible comparison point. That's not an
example of "designing computer software like a game engine", it's more
an example of "designing a game engine like a GUI application", which
is completely backwards. Optimising Unity games is
On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky
(Abscissa) wrote:
suggestion that Robert could get this going an order of
magnitude faster without too terribly much trouble. Luckily,
Ethan explained my stance better than I was able to.
I think you guys overestimate the importance of
On 5/26/19 9:32 PM, Ola Fosheim Grøstad wrote:> > Why do you guys insist
on him doing it your way?
I never said that. And just to further clarify, I also never said he
should USE a game engine for this.
I was only responding to the deluge of misinformation about
game-engine-like approaches,
On Monday, 27 May 2019 at 01:52:05 UTC, Manu wrote:
I don't insist, I was just inviting him to the chat channel
where a similar effort is already ongoing, and where there are
perf experts who can help.
Yes, sure, is always a good thing to hash out ideas with others
who have an interest in
On Sun, May 26, 2019 at 6:35 PM Ola Fosheim Grøstad via
Digitalmars-d-announce wrote:
>
> On Monday, 27 May 2019 at 00:33:45 UTC, Nick Sabalausky
> (Abscissa) wrote:
> > flat-out wrong) to say about game programming. People hear the
> > word "game", associate it with "insignificant" and promptly
On Monday, 27 May 2019 at 00:33:45 UTC, Nick Sabalausky
(Abscissa) wrote:
flat-out wrong) to say about game programming. People hear the
word "game", associate it with "insignificant" and promptly
shut their brains off.
Not insignificant, but also not necessarily relevant for the
project in
On 5/25/19 7:23 PM, Ethan wrote:
[...]
+1 (trillion)
In my entire software career, I have yet to ever come across even one
programmer without direct game engine experience who actually has
anything intelligent (or otherwise just simply NOT flat-out wrong) to
say about game programming.
On Sunday, 26 May 2019 at 18:37:49 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote:
AFAIK Ganesh sucked and it was dropped. They use nv path
rendering now.
https://developer.nvidia.com/nv-path-rendering
Ah, do you know if this is in Chromium as well, or is
On Sunday, 26 May 2019 at 17:41:01 UTC, NaN wrote:
On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote:
On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce
wrote:
What? ... this thread is bizarre.
Why would a high quality SVG renderer decide to limit to 16x
AA? Are
you suggesting
On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote:
AFAIK Ganesh sucked and it was dropped. They use nv path
rendering now.
https://developer.nvidia.com/nv-path-rendering
Ah, do you know if this is in Chromium as well, or is it
something that is closed off to Chrome?
I also noticed that
On Sunday, 26 May 2019 at 17:36:20 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 26 May 2019 at 16:56:39 UTC, Ola Fosheim Grøstad
wrote:
If the SVG renderer in the browser is relevant? Depends. SVG
is animated through CSS, so the browser must be able to redraw
on every frame. For some interfaces
On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote:
On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce
wrote:
What? ... this thread is bizarre.
Why would a high quality SVG renderer decide to limit to 16x
AA? Are
you suggesting that they use hardware super-sampling to render
On Sunday, 26 May 2019 at 16:56:39 UTC, Ola Fosheim Grøstad wrote:
If the SVG renderer in the browser is relevant? Depends. SVG is
animated through CSS, so the browser must be able to redraw on
every frame. For some interfaces it certainly would be
relevant, but I don't think Robert is aiming
On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote:
How is the web browser's SVG renderer even relevant? I have
absolutely no idea how this 'example' (or almost anything in
this thread) could be tied to the point I made way back at the
start before it went way off the rails. Just stop, it's
On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce
wrote:
>
> On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote:
> > On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote:
> >>
> >> Browsers are actually doing quite well with simple 2D graphics
> >> today.
> >
> > Browsers
On 2019-05-25 23:23:31 +, Ethan said:
Right. I'm done. This thread reeks of a "Year of Linux desktop"
mentality and I will also likely never read it again just for my sanity.
That's your best statement so far. Greate move.
--
Robert M. Münch
http://www.saphirion.com
smarter | better |
On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote:
Oh, hey, wait a minute, Nick's dcompute could be exactly what
you're want if you're only doing this to show a UI framework
FWIW, OpenCL is deprecated on OS-X.
You should use Metal for everything.
GPU-APIs are not very future proof.
On Sunday, 26 May 2019 at 11:09:52 UTC, NaN wrote:
Chrome is still doing path rendering on the CPU for me. (I did
make sure that the "use hardware acceleration when available"
flag was set in the advanced settings.)
*nods* Switching hardware acceleration on/off has very little
impact on my
On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote:
On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote:
Browsers are actually doing quite well with simple 2D graphics
today.
Browsers have been rendering that on GPU for years.
Just because (for example) Chrome supports GPU
On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote:
But you shouldn't design a UI framework like a game engine.
Wrong. Game engines excel at laying out high-fidelity data in
sync with a monitor's default refresh rate.
You are confusing rendering engine with UI API.
A game engine is
On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote:
So. On a 4K or higher desktop (Apple shift 5K monitors). Let's
say you need to redraw every one of those 3840x2160 pixels at
60Hz. Let's just assume that by some miracle you've managed to
get a pixel filled down to 20 cycles. But that's
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.
This entire thread is an embarrassment, and a perfect example of
the kind of interaction that keeps professionals away from online
On Saturday, 25 May 2019 at 19:35:35 UTC, user1234 wrote:
Maybe at the beginning everybody will be happy but at the end
people would start using slower scripting languages, less
optimized, or more simply would use those existing to achieve
more complex tasks and after a while the situation we
On Saturday, 25 May 2019 at 19:10:44 UTC, Ron Tarrant wrote:
On Thursday, 23 May 2019 at 00:34:42 UTC, H. S. Teoh wrote:
And this isn't just for mobile apps; even the pervasive
desktop browser nowadays seems bent on eating up as much CPU,
memory, and disk as physically possible
This has
On Thursday, 23 May 2019 at 00:34:42 UTC, H. S. Teoh wrote:
And this isn't just for mobile apps; even the pervasive desktop
browser nowadays seems bent on eating up as much CPU, memory,
and disk as physically possible
This has been going on ever since the Amiga 1000, Atari 1040ST,
and the
On 2019-05-24 23:35:18 +, Exil said:
Is the source available anywhere? Would be interesting to look through
unless this is close source?
No, not yet. Way to early and because we can't support it in anyway.
I see that there is quite some interest in the topic, but I think we
should get
Is the source available anywhere? Would be interesting to look
through unless this is close source?
On Friday, 24 May 2019 at 19:32:38 UTC, Nick Sabalausky
(Abscissa) wrote:
Wow, you're just deliberately *trying* not to listen at this
point, aren't you? Fine, forget it, then.
I have no problem listening. As far as I can tell generic
scenegraph frameworks like Inventor, Ogre (and I presume
On 5/23/19 5:01 PM, Ola Fosheim Grøstad wrote:
On Thursday, 23 May 2019 at 20:20:52 UTC, Nick Sabalausky (Abscissa) wrote:
flexibility. And I think you're *SEVERELY* underestimating the
flexibility of modern game engines. And I say this having personally
used modern game engines. Have you?
On 25/05/2019 5:33 AM, Ola Fosheim Grøstad wrote:
On Friday, 24 May 2019 at 17:19:23 UTC, rikki cattermole wrote:
Be careful with that assumption. Server motherboards made by Intel
come with GPU's as standard.
Yes, they also have CPUs with FPGAs... And NVIDIA has embedded units
with crazy
On Friday, 24 May 2019 at 17:19:23 UTC, rikki cattermole wrote:
Be careful with that assumption. Server motherboards made by
Intel come with GPU's as standard.
Yes, they also have CPUs with FPGAs... And NVIDIA has embedded
units with crazy architectures, like this entry level mode ($99?):
On 25/05/2019 5:04 AM, Robert M. Münch wrote:
On 2019-05-24 10:12:10 +, Ola Fosheim Grøstad said:
I guess server rendering means that you can upgrade the software
without touching the clients, so that you have a network protocol that
transfers the graphics to a simple and cheap
On 2019-05-24 10:12:10 +, Ola Fosheim Grøstad said:
I guess server rendering means that you can upgrade the software
without touching the clients, so that you have a network protocol that
transfers the graphics to a simple and cheap client-display. Like, for
floor information in a
On Friday, 24 May 2019 at 08:42:48 UTC, Robert M. Münch wrote:
Currently we don't use a GPU, it's only CPU based. I think CPU
rendering has its merits and is underestimated a lot.
+1
One big bottleneck for CPU renderer is pixel upload, but apart
from that it's pretty rad.
On Friday, 24 May 2019 at 08:42:48 UTC, Robert M. Münch wrote:
Well, the main market I see for a software renderer is the
embedded market and server rendering. Making money with
development tools, components or frameworks is most likely only
possible in the B2B sector.
Indeed. Software that
On Friday, 24 May 2019 at 08:35:27 UTC, Robert M. Münch wrote:
I'm not fully understand the discussion about accuracy WRT
GUIs. Of course you need to draw things accurate. And my
interjection WRT 35-FPS was just to give an idea about the
possible achievable performance. I like desktop apps
On 2019-05-23 17:27:09 +, Ola Fosheim Grøstad said:
Yeah, that leaves a lot of headroom to play with. Do you think there is
a market for a x86 CPU software renderer though?
Well, the main market I see for a software renderer is the embedded
market and server rendering. Making money with
On 2019-05-23 20:22:28 +, Ola Fosheim Grøstad said:
STILL, I think Robert M. Münch is onto something good if he aims for
accuracy and provides say a canvas that draws bezier curves to the spec
(whether it is PDF or SVG). I think many niche application areas
involve accuracy, like a CNC
On 2019-05-23 19:29:26 +, Ola Fosheim Grøstad said:
When creating a user interface framework you should work with
everything from sound editors, oscilloscopes, image editors, vector
editors, CAD programs, spreadsheets etc. You cannot really assume much
about anything. What you want is max
On Thursday, 23 May 2019 at 20:20:52 UTC, Nick Sabalausky
(Abscissa) wrote:
flexibility. And I think you're *SEVERELY* underestimating the
flexibility of modern game engines. And I say this having
personally used modern game engines. Have you?
No, I don't use them. I read about how they are
On 5/23/19 3:52 PM, Ola Fosheim Grøstad wrote:
On Thursday, 23 May 2019 at 19:32:28 UTC, Nick Sabalausky (Abscissa) wrote:
Game engines *MUST* be *EFFICIENT* in order facilitate the demands the
games place on them. And "efficiency" *means* efficiency: it means
minimizing wasted processing, and
On Thursday, 23 May 2019 at 20:13:29 UTC, Nick Sabalausky
(Abscissa) wrote:
They want accuracy TO THE EXTENT THEY (and others) CAN PERCEIVE
IT. That is the key. Human perception is far more limited than
most people realize.
Well, what I meant by "cutting corners" it that games reach
On 5/22/19 8:34 PM, H. S. Teoh wrote:
And this isn't just for mobile apps; even the pervasive desktop browser
nowadays seems bent on eating up as much CPU, memory, and disk as
physically possible -- everybody has their neighbour's dog wants ≥60fps
hourglass / spinner animations and smooth
On 5/23/19 3:29 PM, Ola Fosheim Grøstad wrote:
On Thursday, 23 May 2019 at 19:13:11 UTC, Nick Sabalausky (Abscissa) wrote:
Serious photographers and videographers use things like JPEG and MPEG
which are *fundamentally based* on cutting imperceptible corners and
trading accuracy for other
On Thursday, 23 May 2019 at 19:32:28 UTC, Nick Sabalausky
(Abscissa) wrote:
Game engines *MUST* be *EFFICIENT* in order facilitate the
demands the games place on them. And "efficiency" *means*
efficiency: it means minimizing wasted processing, and that
*inherently* means *both* speed and
On Thursday, 23 May 2019 at 19:29:26 UTC, Ola Fosheim Grøstad
wrote:
Most GUI frameworks fail at this, so you have to do all
yourself if you want anything with descent quality, but that is
not how it should be.
I meant «decent»! *grin*
(But really, photographers and videographers use RAW
On 5/22/19 6:33 PM, H. S. Teoh wrote:
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 wrote:
[...]
But you shouldn't design a UI framework like a game engine.
Especially not if
On Thursday, 23 May 2019 at 19:13:11 UTC, Nick Sabalausky
(Abscissa) wrote:
Serious photographers and videographers use things like JPEG
and MPEG which are *fundamentally based* on cutting
imperceptible corners and trading accuracy for other benefits.
The idea of a desktop GUI absolutely
On 5/22/19 6:39 PM, Ola Fosheim Grøstad wrote:
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
On Thursday, 23 May 2019 at 16:36:17 UTC, Robert M. Münch wrote:
When doing the real-time resizing in the screencast, the CPU
usage is around 5% - 6%
Yeah, that leaves a lot of headroom to play with. Do you think
there is a market for a x86 CPU software renderer though?
Or do you plan on
On 2019-05-23 07:28:49 +, Ola Fosheim Grøstad said:
On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote:
On 2019-05-22 17:01:39 +, Manu said:
I mean, there are video games that render a complete screen full of
zillions of high-detail things every frame!
Show me a game
On 2019-05-23 09:28:59 +, kdevel said:
Awesome. Compared to the video you posted some days ago there is also
almost no visible aliasing.
Thanks.
Do you plan to create a web browser based on your framework?
No, I don't see any business model behind a web browser...
--
Robert M. Münch
On Thursday, 23 May 2019 at 01:22:20 UTC, Manu wrote:
That's a different discussion. I don't actually endorse this.
I'm a fan of instantaneous response from my productivity
software... 'Instantaneous' being key, and running without
delay means NOT waiting many cycles of the event pump to flow
On Wednesday, 22 May 2019 at 21:18:58 UTC, Manu wrote:
People really should look at games for how to write good
software in general.
While I agree for some AAA games (and I'm sure your employer can
afford excellent development practics), I'd like to counteract
that point for balance: for
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
I optimized the whole thing a bit, so now a complete screen
with layouting, hittesting, drawing
On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote:
On 2019-05-22 17:01:39 +, Manu said:
I mean, there are video games that render a complete screen
full of zillions of high-detail things every frame!
Show me a game that renders this with a CPU only approach into
a memory
On 2019-05-22 17:01:39 +, Manu said:
The worst case defines your application performance, and grids are
pretty normal.
That's true, but responsive grids are pretty unusal.
You can make a UI run realtime ;)
I know, that's what we seek for.
I mean, there are video games that render a
On Thursday, 23 May 2019 at 00:23:50 UTC, Manu wrote:
it's really just a style
of software design that lends to efficiency.
Our servers don't draw anything!
Then it isn't specific to games, or particularly relevant to
rendering. Might as well talk about people writing search engines
or
On Wed, May 22, 2019 at 5:34 PM H. S. Teoh via Digitalmars-d-announce
wrote:
>
> On Wed, May 22, 2019 at 05:11:06PM -0700, Manu via Digitalmars-d-announce
> wrote:
> > On Wed, May 22, 2019 at 3:33 PM H. S. Teoh via Digitalmars-d-announce
> > wrote:
> > >
> > > On Wed, May 22, 2019 at 02:18:58PM
On Wed, May 22, 2019 at 05:11:06PM -0700, Manu via Digitalmars-d-announce wrote:
> On Wed, May 22, 2019 at 3:33 PM H. S. Teoh via Digitalmars-d-announce
> wrote:
> >
> > On Wed, May 22, 2019 at 02:18:58PM -0700, Manu via Digitalmars-d-announce
> > wrote:
[...]
> > > I couldn't possibly agree
On Wed, May 22, 2019 at 3:40 PM Ola Fosheim Grøstad via
Digitalmars-d-announce wrote:
>
> 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
> >
On Wed, May 22, 2019 at 3:33 PM H. S. Teoh via Digitalmars-d-announce
wrote:
>
> 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 wrote:
> [...]
> > > But you shouldn't
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
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 wrote:
[...]
> > But you shouldn't design a UI framework like a game engine.
> >
> > Especially not if you also want to run on
On Wed, May 22, 2019 at 10:20 AM Ola Fosheim Grøstad via
Digitalmars-d-announce 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
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
On Tue, May 21, 2019 at 12:55 PM Robert M. Münch via
Digitalmars-d-announce wrote:
>
> On 2019-05-21 16:51:43 +, 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*
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
On 2019-05-21 16:51:43 +, 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 :-)
1 - 100 of 112 matches
Mail list logo
