windows: On Windows (inside VirtualBox), repaint performance is horrendous.

[joeblew99]

On Windows (inside VirtualBox), repaint performance is horrendous.

Video is here:
https://www.youtube.com/watch?v=TjIqIA7EV14

Test Harness is here:
https://bitbucket.org/gedw99/md-desktopnative-x

# go 1.7

go env
set GOARCH=amd64
set GOBIN=C:\Users\root\workspace\go\bin
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\root\workspace\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\root\AppData\Local\Temp\go-build476382774=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1

go get bitbucket.org/gedw99/md-desktopnative-x

cd cmd/01

# build it
go build

# run it
./01

---

It could be because i am inside Virtual box.
If anyone else is on windows i would like to know how it performs for you.

[andlabs]

The algorithm to do layout and sizing is not optimal. Optimizing this is a long term goal; I would need a native Windows box to be absolutely sure of the performance.

[joeblew99]

Well its not bad on osx. I would guess the perf is at least 20 times faster than on windows. its quite ok.
Here is a video on OSX:
https://www.youtube.com/watch?v=Vy85gKOxSbk

So, what i am wondering is if its a Windows specific perf thing or VBox thing.

So, if anyone has a Windows box, please try this out.

[andlabs]

Yes, it's specific to Windows, because of how the resizes work on Windows. I have to do it manually, and it's using a very poor algorithm right now. I'm not sure if VBox is making the performance any worse, though.

[lxn]

It's the same on native Windows. I recently "upgraded" from W7 to W10 and have the impression it got a bit better, but still very slow.

[andlabs]

Right. I have several ideas for optimizations, but until I can get a physical machine set up again (I have one; I just have to back up my files and remove the Linux partition) I can't tell, and I'd rather not throw darts at the wall that involve massive restructurings again — this time I have to be sure.

[joeblew99]

thanks all for the feedback.

I used to use a 200 euro Intel nice for this type of testing. Cheap and easy

[lxn]

Actually it's not a layout problem. Some profiling suggests getControlBackgroundBrush and paintContainerBackground to be the bad guys.

Commenting out the WM_CTLCOLORSTATIC and WM_CTLCOLORBTN handlers in handleParentMessages in file parent.cpp as well as the WM_PAINT and WM_PRINTCLIENT handlers in containerWndProc in file container.cpp makes it fly, albeit looking ugly.

[andlabs]

Hm, thanks for finding that! Not sure how to fix that, though...

[joeblew99]

Hey all.

@lxn I am guessing this is the fix:
andlabs/libui#202

thanks allot. I will be trying it out asap !

[lxn]

No, that's another issue.

Fixing #184 won't be that simple.

[joeblew99]

@lxn
These files yo changed are in the c / c++ repo https://github.com/andlabs/libui/ ?

i am thinking if i can help with compiling them so i can help and move forward.
i am a golang programmer and have only done a little of cmake & c programming

[emersion]

@joeblew99 This repo won't be updated until a new libui version is published. At ProtonMail we maintain a fork with latest builds and fixes (https://github.com/ProtonMail/ui). I'll test this patch and probably update builds on our repo this afternoon.

[joeblew99]

That is awesome - thanks.

I will try it out this afternoon.

I wish I could help with it, but I might be more of a time drain asking too many question I fear.
Let me know though...

[joeblew99]

@emersion

thanks. i changed over to using your repo (https://github.com/ProtonMail/ui)
I have 2 test harnesses and they all worked with you code :)

I will look out for your commits, so i can try out doing cross builds for linux and windows, and also new UX combinations of things.

If you manage to fix this issues (slow UI on Windows), i can also try from my side too.

If you want me to try anything out, feel free to buzz me..

[lxn]

Looked at this again without much success, but maybe this helps:
The performance problem is solved by following the steps outlined in my comment on this issue from August 26, leaving us with ugly backgrounds of labels and some other controls.

It seems those controls are painted correctly, if they are direct children of a tab page.
This can quickly be tried by adding a label or any other offender to the empty page of the test program.
Nested tabs would also paint nicely, if they had no internal container.

I then modified container to be a dialog, but couldn't make it look right...

[andlabs]

Oh, so the controls know how to paint themselves properly in a themed dialog texture dialog window? Flattening the container hierarchy would be the correct solution to the problem if that's the case, but would make things much more complicated (in fact, early package ui did exactly this!). (Indeed, groupboxes should not themselves be parents either!) You get a heart for that anyway; theme dialog textures are super fun voodoo magic including for a variety of other reasons that are outside the scope of this post...

[lxn]

It seems whether or not calling EnableThemeDialogTexture doesn't even make a difference. (At least on Windows 10.)

Going the windowless container route should be tough, but maybe the right approach.

For my walk package, I had considered trying to do grid layouts which could span an arbitrary amount of containers, think contents of group boxes on a complex dialog, to improve overall alignment of controls. Probably not worth the trouble though.

[andlabs]

You could try doing it the GTK+ way: GtkSizeGroup. It constrains arbitrary widgets to have the same width or height, regardless of their location in the widget hierarchy, and with their containers cooperating. Of course, it's that last part that'll make things a bit tougher...

[lxn]

Just pushed some related changes to walk, which improve background handling.

Before this commit, walk suffered from the ugly gray background problem with labels and some other controls, when placed on a tab page.

It seems the only problem left is this.

Maybe you could do something similar in libui.

[copygirl]

I'd like to note that I experience the same problem on my Windows 7 PC using noliar/DevZH.UI.

[zhaozg]

please with high properties,or any patch

[andlabs]

Fixing this without making things ugly would be a major undertaking; a simple patch will not suffice, and it might be pushed to after the Alpha 4 release (which might be called 0.4.0). A simple patch would suffice if you didn't mind things looking bad, but that would still wait for after I gain copyright clearance from my new employer.

[zhaozg]

Thanks @andlabs I will wait

[zhaozg]

#184 (comment) works for me fine.

[andlabs]

Right, but you now see the blotches of gray in the themed controls? That was what the code I had written tried to address, and what lxn says will be fixed by flattening the control hierarchy. However, doing this would require me to rework uiControl and uiWindowsControl again, which would not be a quick fix. It will happen, but it will take time.

If more people now are willing to deal with the ugly UI, that's fine; I am concerned about new people who don't know about this issue, though.

[lxn]

@andlabs You actually don't need to flatten the control hierarchy. In walk I was faced with the same problem and somehow got to a workable solution which also allows for arbitrary control backgrounds including gradients using good old GDI only. Performance is good also.

This should be all the code that's needed:
https://github.com/lxn/walk/blob/master/container.go#L372-L375
https://github.com/lxn/walk/blob/master/window.go#L1498-L1597
https://github.com/lxn/walk/blob/master/window.go#L1607-L1631

Fix for this tab control issue:
https://github.com/lxn/walk/blob/master/tabwidget.go#L327-L481

[andlabs]

So what, what are you doing differently? Using WM_ERASEBKGND instead of WM_CTLCOLORSTATIC? And what is the perWindowBrush logic? Also I thought the tab control already did the WM_PRINTCLIENT logic...

[lxn]

The main difference seems to be that in getControlBackgroundBrush, which is called for each WM_CTLCOLOR*, you create a bitmap as target for a WM_PRINTCLIENT of the parent and then create a pattern brush using the bitmap. In walk I don't do any expensive things like this when handling WM_CTLCOLOR*.

perWindowBrush enables using a single GradientBrush as background for multiple windows. It manages the association of a BitmapBrush / pattern brush to a window and updates these delegate brushes when window sizes change.

In walk I had to paint the free area not occupied by tab items so it doesn't paint gray over the parent's background. That's probably taken care of by the bitmap + WM_PRINTCLIENT + pattern brush combo in libui.

[andlabs]

Moving this to andlabs/libui#311.