After spending some time playing with existing GUI libraries for my game, I've decided to look into rolling my own. My needs are fairly simple, but more dynamic than the libraries I tested seem to be designed for. Until now, I assume that this would involve rendering lots of quads to textures (one texture per panel or window in the UI), and then rendering these textures on quads onto the screen.
However, after searching around for other ways to implement this, I came across this post, where swiftcoder suggests composing the UI on the CPU rather than the GPU, and then just blitting the resulting texture to a screen quad from there. I had never considered this method before, but I'm intrigued.
Has anyone else done this? What were your experiences with it? It seems like you would have more freedom in designing the UI since you're not having to send each piece as geometry to the GPU, but on the other hand I don't have much idea how to edit textures on the CPU either. Would uploading final textures each frame to the GPU really be faster than sending the individual quads to the GPU?
Swiftcoder mentioned two libraries for composing UIs on the CPU, Skia and Cairo. Has anyone used these for games? Are there others like this? I'm more inclined to do it myself rather than use a library, but I'm curious what all is out there, and haven't managed to find others from my own searching.
UI compositing on CPU?
- Has anyone else done this?
- It seems like you would have more freedom in designing the UI since you're not having to send each piece as geometry to the GPU...
- I don't have much idea how to edit textures on the CPU either.
- Would uploading final textures each frame to the GPU really be faster than sending the individual quads to the GPU?
- Skia and Cairo ...
- I have not but now that I think at it, it seems a very valuable suggestion. I will have to consider this seriously.
- I don't think so. But perhaps it will save on the required effort.
- I suppose the key point here is everything being 2D, therefore we're talking about moving quads around. Then, it's just a matter of rasterizing them to a bidimensional array of pixels. When no zooming or rotation is involved, this is much easier than a full rasterization and might eventually degenerate to a memory copy. There might be the need to implement some blending modes, I'd take those straight out of OpenGL spec.
- I don't think performance is going to be an issue anyway.
- I have looked at Cairo some time in the past, it was overkill for my needs. Personally I'd give a try to Skia. Why to use a library? I stated above that everything is "simple enough" when using full 2D with no zooming or rotation. This is in my opinion, fairly restrictive. Furthermore, antialiasing is absolutely required IMHO to obtain a decent quality. I say this for experience as my current anti-aliasing methods sucks bad. When we pull the requirements together, it appears to me that using a library is The Right Way.
To be fair, my primary motivation for moving UI compositing to the CPU was font rendering.
Current font rendering techniques using OpenGL are needlessly involved to implement on OpenGL 3+, and also are a silly performance bottleneck. Plus, unicode font rendering is really complex to write from scratch.
Current font rendering techniques using OpenGL are needlessly involved to implement on OpenGL 3+, and also are a silly performance bottleneck. Plus, unicode font rendering is really complex to write from scratch.
Author
That certainly makes sense, fonts seem to be the most complex part of drawing UI.
I assume the bottleneck you are referring to is the method of drawing text as a series of individual quads? I'm curious whether that is actually slower than directly rendering the string of text to a texture using Freetype every time it changes (which might be every few frames), given that Freetype isn't particularly fast itself.
If there is a third option, I'd be very interested to know what it is. I know you've talked about Skia and Cairo, I'd be interested in finding out how they do quicker font rendering, rather than using them directly.
I assume the bottleneck you are referring to is the method of drawing text as a series of individual quads? I'm curious whether that is actually slower than directly rendering the string of text to a texture using Freetype every time it changes (which might be every few frames), given that Freetype isn't particularly fast itself.
If there is a third option, I'd be very interested to know what it is. I know you've talked about Skia and Cairo, I'd be interested in finding out how they do quicker font rendering, rather than using them directly.
I know you've talked about Skia and Cairo, I'd be interested in finding out how they do quicker font rendering, rather than using them directly.
The issue isn't really performance at all, it's that Skia and Cairo can render full unicode fonts. If you ever want to localise your game in, for example, Arabic, then you'll need to integrate a fully-fledged text API anyway (Sanskrit, Arabic, etc. are not character-based languages - you can't render them just by throwing a sequence of quads at the screen).
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]I'm curious whether that is actually slower than directly rendering the string of text to a texture using Freetype every time it changes (which might be every few frames), given that Freetype isn't particularly fast itself.[/quote]
[/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]FreeType is just a font API, it doesn't handle text rendering. To get anywhere close to full unicode support, you need pango instead. I'd suggest you read more about text rendering.
[/font]
Where you might gain performance, is by freeing up the GPU to handle a more expensive task, like actual 3D rendering, or physics simulation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
