GWork new renderers: Irrlicht, GL Core, software.

GWork now has some new renderers:

Software

The software renderer has been added so that we can render a GUI without an external rendering API being a dependency. We can render to a texture and save this out. At some point this may be used for comparisons in testing.

It also means that you can add GWork to you project and just render the resultant API as the texture produced by the software renderer. It could be a lazy way to add it!

OpenGL Core

An OpenGL Core renderer was added by Megaxela.

Irrlicht

An Irrlicht renderer was added by kklouzalk.

Gwork GUI DirectX 11 Renderer

I added a DirectX 11 renderer to Gwork. Thanks to Github user Topblast for the original code. I had to make a few modifications:

• The Windows DirectX SDK no longer includes the D3DX extensions. These can be used to compile shaders and load bitmaps. Instead we use the D3D API and STB image.
• The Pixel colour sampler also seemed to not read the alpha channel so instead we use the STB image that is retained. Eventually, I'd like to move all the skin config into a single data file so things are more data driven so this is somewhat temporary.
• Fixed the Gwork Windows platform. This means things like the clipboard should work.

Gwork Continuous Integration

I added a Null renderer to Gwork, i.e. one that doesn't draw anything. This makes it easier to do things like cross-platform build testing. We might check several different configs of the build without having to link to a graphical API.

This is useful because if anyone submits any patches to Gwork they will be tested in the pull-request queue. Users can also add tests builds their own Travis accounts so they can see if their fork is building.

Travis

For Linux and MacOS (OSX) builds I used Travis. It is a free service, so I can't complain too much, but it took a considerable amount of fiddling around to get Linux builds working. I won't bore you with the details.

Travis current live build status:

Gwork memory allocation stats

I added memory allocation tracking to Gwork as I'd like to keep track of the number and size of allocations. A CSV file is generated which parsed to produce a report. The following are tables from the report.

Current state

The current Gwork allocation stats from:

commit a95a0fde3afb68d2fd4d7af817159c4891db970d

AuthorDate: Mon Aug 15 20:26:21 2016 +0100

Name	Alloc count	Alloc size
API test	9018	1566856 (1530.133KB)
Button	53	11024 (10.766KB)
Checkbox	34	6088 (5.945KB)
CollapsibleList	208	39744 (38.812KB)
ColorPicker	281	32680 (31.914KB)
ComboBox	4194	755408 (737.703KB)
CrossSplitter	54	11128 (10.867KB)
GroupBox	13	3928 (3.836KB)
ImagePanel	6	1248 (1.219KB)
Label	45	8168 (7.977KB)
LabelMultiline	36	8736 (8.531KB)
ListBox	252	46040 (44.961KB)
MenuStrip	817	153304 (149.711KB)
Numeric	39	5056 (4.938KB)
PageControl	58	11568 (11.297KB)
ProgressBar	72	9728 (9.500KB)
Properties	608	83240 (81.289KB)
RadioButton	62	12072 (11.789KB)
ScrollControl	602	113640 (110.977KB)
Slider	34	5040 (4.922KB)
StatusBar	10	2000 (1.953KB)
TabControl	181	34016 (33.219KB)
TextBox	234	23080 (22.539KB)
TreeControl	714	117984 (115.219KB)
Window	14	2712 (2.648KB)

GWEN stats

Name	Alloc count	Alloc size
API test	10051	1721899 (1681.542KB)
Button	62	11736 (11.461KB)
Checkbox	35	6152 (6.008KB)
CollapsibleList	229	40952 (39.992KB)
ColorPicker	341	36256 (35.406KB)
ComboBox	4742	792208 (773.641KB)
CrossSplitter	63	15352 (14.992KB)
GroupBox	15	10264 (10.023KB)
ImagePanel	8	1408 (1.375KB)
Label	53	9304 (9.086KB)
LabelMultiline	41	18920 (18.477KB)
ListBox	289	66771 (65.206KB)
MenuStrip	983	203992 (199.211KB)
Numeric	44	5216 (5.094KB)
PageControl	64	12096 (11.812KB)
ProgressBar	73	10016 (9.781KB)
Properties	661	80348 (78.465KB)
RadioButton	68	12592 (12.297KB)
ScrollControl	574	105864 (103.383KB)
Slider	34	4912 (4.797KB)
StatusBar	11	2144 (2.094KB)
TabControl	182	41952 (40.969KB)
TextBox	306	37552 (36.672KB)
TreeControl	727	121572 (118.723KB)
Window	16	2856 (2.789KB)

As you can see the "unit test" from GWEN use 1681.542KB, with Gwork using 1530.133KB. So that's roughly 160KB smaller. Note, this is from the gwen branch in the Gwork repo. 

Comparison

There is a more detailed comparison below.

Name	Count delta	Size delta	% size
API test	-1063	-163051 (-159.229KB)	90.5%
Button	-9	-712	93.9%
Checkbox	-1	-64	99.0%
CollapsibleList	-21	-1208 (-1.180KB)	97.1%
ColorPicker	-64	-3752 (-3.664KB)	89.7%
ComboBox	-548	-36800 (-35.938KB)	95.4%
CrossSplitter	-9	-4224 (-4.125KB)	72.5%
GroupBox	-2	-6336 (-6.188KB)	38.3%
ImagePanel	-2	-160	88.6%
Label	-8	-1136 (-1.109KB)	87.8%
LabelMultiline	-5	-10184 (-9.945KB)	46.2%
ListBox	-37	-20731 (-20.245KB)	69.0%
MenuStrip	-166	-50688 (-49.500KB)	75.2%
Numeric	-5	-160	96.9%
PageControl	-7	-776	93.6%
ProgressBar	-1	-288	97.1%
Properties	-53	2892 (2.824KB)	103.6%
RadioButton	-6	-520	95.9%
ScrollControl	4	200	100.2%
Slider	0	128	102.6%
StatusBar	-1	-144	93.3%
TabControl	-1	-7936 (-7.750KB)	81.1%
TextBox	-72	-14472 (-14.133KB)	61.5%
TreeControl	-13	-3588 (-3.504KB)	97.0%
Window	-2	-144	95.0%

There isn't much detail about where the savings come from but the unicode string changes will have had an effect. GWEN stored every control string as wide unicode and as ASCII. LabelMultiline has a considerable saving, probably due to this. Interesting that a couple are larger than GWEN. Will have to investigate this.

Future Work

This gives a reference point on which to compare any future memory saving work. Work here might include:

• Event system refactor. This is pretty inefficient as every control contains listeners and the associated containers whether used or not.
• Type size and reordering. E.g. booleans might be better as chars, enums as chars etc. These might also be more efficient packed in the controls by reordering them.

Gwork update

Have done a fair amount of refactoring of Gwork of late. This recently went into mainline on Github.

Architecture

Have restructured the source folders. We now have:

        source/
               platform/
               gwork/
               util/
               test/
               designer/
               samples/

This reflects the dependencies in the project, with each parent folder relying on the child folders above it. There are no dependencies from child to parent! Previously things like input and rendering were a little intertwined with the controls. Ideally, once you get to the gwork level everything should be platform agnostic.

Cmake

Gwork now has a cmake build system. Premake just moves too glacially and still doesn't have proper support for mobile platforms like iOS. Cmake is a little intimidating at first, but worth it due to its capabilities and range of outputs. It has full support for Ninja, which is pretty zippy, and handy when testing.

Renaming

I finally got round to renaming GWEN to Gwork (or "Gwk" namespace in the project). It has changed pretty significantly with the direction structure refactoring and worthy of a rename. Don't want confusion between the original project and this one.

GWEN SDL2 GUI Renderer

To try out the new SDL2 SDK I ported GWork (a fork of GWEN) to it.

It mostly went across quite easily, apart from reading pixel values, which GWEN uses to get the colours used when drawing. It is difficult to read pixels in a texture as you don't know the format, so I had to keep a surface. Apart from that though it was fairly easy.

SDL2 renderer Mac OSX 10.8

SDL2 renderer Windows 7

Please read the readme at the Github project for more details. If you have any problems report them at the issue tracker.

Enjoy.

[8/9/13] Premake works for Windows now.

UI for Allegro 5

I found a nice UI system called GWEN. It has lots of advanced features and is very easy to embed. It sits nicely on top of your application and can just be wired into its resources, to save competing systems, e.g. input or texture management.

Example of Gwen UI from the Gwen site.

I ported it to Allegro 5, which was quite easy as the renderer and input abstractions are well designed. I did it on the Mac, but it also works just fine on my old Windows XP laptop. Gwen also provides rendering backends for OpenGL, DirectX, SFML, and Windows GDI.

[Note] I have forked GWEN in order to fix various issues with Allegro 5, etc. There are notes in the readme and on the wiki. You may want to prefer this version if you are using Allegro 5. Please report any issues in the Github issue tracker for Gwork.

If you have used Delphi, or Windows Forms you'll probably find it quite easy to pick up. There are unit test examples from which to learn, but other than that you have to plough through the code at the moment. Hopefully more docs and comments will appear soon to ease the learning curve. There is a small tutorial on doing layout with docking.

One of the things that is really nice about Gwen is the skinning system. It is all laid out in one bitmap, along with the colour scheme at the bottom.

The default skin for Gwen.