[dlangui Example1] Window Performance problems in Windows 10

[BoQsc]

On the left a random program (CyberDuck)
On the right - dlangui Example.

2021-07-10.15-56-49.mp4

[GrimMaple]

I tested it on the most recent commit and didn't see any jittering. Is this still an issue?

[Superbelko]

I think this is only noticeable in debug builds, optimized builds using LDC is fast enough even on 4k resolution.

[BoQsc]

The performance issues might only be noticible on a lower-end computer.

[Superbelko]

Yeah, but for me it looks more like an layout issue (also flicker issue) rather than performance issue, like as if it is doing wrong measurements and then constantly overshoot desired sizes in both ways causing this ugly visual jitter.

Anyway, "example1" is more like stress test, in more simpler layouts it should be much more performant.

[Superbelko]

I tried profiling it a bit, it doesn't looks like GC or memory issue, it seems that it spends most of the time waiting for OpenGL (glViewport call is the biggest performance stall here), of course profiling also shows there is tons of measure & layout calls which takes roughly 50% of the frame time and about 30% total CPU time for OpenGL.

[Superbelko]

It seems OpenGL implementation is buggy, for now as a workaround it can be avoided using "minimal" configuration that draws using system graphics instead of OpenGL, using it provides much better CPU utilization (but higher CPU load due to drawing using CPU) and performance (in release builds) without such hiccups.

Here is how to add "minimal" configuration to a project, in dub.json add "configurations" section like this:

dlangui/examples/example1/dub.json

Lines 41 to 46 in d92f668

	{
	"name" : "minimal",
	"subConfigurations" : {
	"dlangui" : "minimal"
	}
	}

And this is how to build it using for example with LDC compiler:
dub build -c minimal --compiler=ldc2 --build release

[GrimMaple]

It seems OpenGL implementation is buggy, for now as a workaround it can be avoided using "minimal" configuration that draws using system graphics instead of OpenGL, using it provides much better CPU utilization (but higher CPU load due to drawing using CPU) and performance (in release builds) without such hiccups.

Here is how to add "minimal" configuration to a project, in dub.json add "configurations" section like this:

dlangui/examples/example1/dub.json

Lines 41 to 46 in d92f668

	{
	"name" : "minimal",
	"subConfigurations" : {
	"dlangui" : "minimal"
	}
	}

And this is how to build it using for example with LDC compiler: dub build -c minimal --compiler=ldc2 --build release

This isn't an OpenGL bug, it's a Windows bug. SwapBuffers on Windows is amazingly slow, and must come along with glFlush AND no vsync enabled. I've had the same issue with my game engine.

I'll take a look at this soon, and try to figure out a solution

[Superbelko]

Makes sense, on Windows all UI is displayed by compositor since Vista, waiting for monitor vsync no longer an option.

So I've quickly googled the problem (esp. chromium discussion about it) and the solution usually involves relying either on wait for compositor after swap using DwmFlush() (didn't worked for me though) or implementing high frequency timer for smooth framerate.

edit: actually it works, however visually it still looks like ugly jittery crap. meh...

edit2: it looks like the actual problem is internal OpenGL implementation that we cannot control, example1 takes on average 2ms frame time on my machine, with average 25ms frame time with spikes up to 40ms when resizing, it seems that after resizing OpenGL does a lot of work internally and we can't do much about it, maybe we can try drawing to FBO instead of back buffer directly and/or move the drawing to another thread but I don't think this will work.