Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


UI compositing on CPU?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Nairou   Members   -  Reputation: 429

Like
1Likes
Like

Posted 20 February 2012 - 01:04 AM

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.

Sponsor:

#2 Krohm   Crossbones+   -  Reputation: 3171

Like
1Likes
Like

Posted 20 February 2012 - 01:54 AM

  • 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.


#3 swiftcoder   Senior Moderators   -  Reputation: 10238

Like
0Likes
Like

Posted 22 February 2012 - 03:18 PM

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.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#4 Nairou   Members   -  Reputation: 429

Like
0Likes
Like

Posted 22 February 2012 - 03:50 PM

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.

#5 swiftcoder   Senior Moderators   -  Reputation: 10238

Like
0Likes
Like

Posted 22 February 2012 - 04:05 PM

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).

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.


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.



Where you might gain performance, is by freeing up the GPU to handle a more expensive task, like actual 3D rendering, or physics simulation.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS