About freeorion's performance

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#46 Post by Geoff the Medio » Mon Jun 29, 2015 6:24 pm

raptor wrote:Could a texture cache be bound only once at application start-up, then just modify the quad coordinates of the glyph when rendering?
If the only texture you ever wanted to render was a font, sure...

raptor
Space Squid
Posts: 75
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#47 Post by raptor » Mon Jun 29, 2015 7:24 pm

Oops. Sorry, I mixed up 'binding' with 'creation', in my head, for some reason... that basically invalidates my line of thought.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#48 Post by Geoff the Medio » Tue Jun 30, 2015 11:49 am


raptor
Space Squid
Posts: 75
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#49 Post by raptor » Tue Jun 30, 2015 4:11 pm

Performance with the new code is almost identical. With a similar test performed like before, the node cost of GG::Font::RenderCachedText is about 19% of the whole. I looked into getting the debug symbols for my drivers but so far, no luck. I'm looking into other ways to figure out which GL calls are the most expensive; any ideas would be appreciated.

raptor
Space Squid
Posts: 75
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#50 Post by raptor » Tue Jun 30, 2015 4:30 pm

I did some more digging and found other methods that call the same symbol. It looks like the issues is indeed glBindTexture().

Looking at other font caching methods (like this one: https://github.com/akrinke/Font-Stash/b ... ash.c#L414), it looks like that glBindTexture() is only ever called when a new glyph needs to be added to the texture cache or when a new texture is created; however, it looks like freeorion calls it on every glyph render.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#51 Post by Geoff the Medio » Tue Jun 30, 2015 6:50 pm

raptor wrote:...it looks like freeorion calls [glBindTexture()] on every glyph render.
Why do you say that? RenderCachedText renders (I think) a whole Control's text (many Glyphs), but only binds and unbinds once. PreRenderText similarly binds once (though I'm not sure why that's necessary...)

Edit: commenting out line 855 of Font.cpp,

Code: Select all

    //glBindTexture(GL_TEXTURE_2D, m_texture->OpenGLId());
seems to have no ill-effects for me. Does it still work for you, possibly with an minor speed improvement?

raptor
Space Squid
Posts: 75
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#52 Post by raptor » Tue Jun 30, 2015 7:28 pm

Commenting out that line in PreRenderText() doesn't change the performance; however, commenting out the two calls in RenderCachedText() does give a slight performance boost (with unacceptable visual artifacts), but not much. Maybe I'm mistaken in thinking it was glBindTexture().

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#53 Post by Geoff the Medio » Thu Jul 02, 2015 10:05 am


raptor
Space Squid
Posts: 75
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#54 Post by raptor » Thu Jul 02, 2015 3:27 pm

This was really good!

FPS increased to about 45-50 FPS (from about 30 before) when viewing the tech-tree the same as with previous tests. I did another callgrind analysis and came up with about a 3.7x performance increase of GG:Font::RenderCachedText() as rough guess. See my numbers:
snapshot2.png
snapshot2.png (69.31 KiB) Viewed 1407 times
Note that there is a huge reduction in number of calls per Render() fram of the TechPanel.

The new largest offender is PartlyRoundedRect() at 14% of the whole, with most of that (10%) in CircleArc(), from CUIDrawUtil.cpp.

Great change!

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#55 Post by Geoff the Medio » Thu Jul 02, 2015 6:22 pm

If a few others could test it out, that would be helpful... I'm a bit hesitant to merge without a few other reports.

User avatar
Vezzra
Release Manager, Design
Posts: 4652
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: About freeorion's performance

#56 Post by Vezzra » Thu Jul 02, 2015 7:52 pm

Geoff the Medio wrote:If a few others could test it out, that would be helpful... I'm a bit hesitant to merge without a few other reports.
I'm still on vacation, will try to get around to it next week.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: About freeorion's performance

#57 Post by MatGB » Thu Jul 02, 2015 8:37 pm

I'm having problems getting Git to recognise the branch you've put the code in, I'm sure I'll figure it out.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Sloth
Content Scripter
Posts: 685
Joined: Sat Mar 17, 2007 12:28 am

Re: About freeorion's performance

#58 Post by Sloth » Thu Jul 02, 2015 9:20 pm

I've pulled the PR, compiled and ran a test. The performance is certainly not worse, but i can't really tell whether it's better.

For me the easiest way to crash my framerate is to build the super testers takeover. With a big galaxy (250+) fully visible it even becomes hard to click on a system, because the mouse cursor reacts so badly.
All released under the GNU GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0 licences.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: About freeorion's performance

#59 Post by MatGB » Thu Jul 02, 2015 10:01 pm

Builds and runs fine, I perceive an improvement in the tech screen but can't quantify it, then I never noticed a reduction in FPS in that window anyway, I've always had low FPS, even on the new machine.

Edit: on the main map window, it's not just a perception, massive improvement in mouse responsiveness and general control over screen and game.
Last edited by MatGB on Thu Jul 02, 2015 10:05 pm, edited 1 time in total.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12268
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: About freeorion's performance

#60 Post by Geoff the Medio » Thu Jul 02, 2015 10:02 pm

Sloth wrote:For me the easiest way to crash my framerate is to build the super testers takeover. With a big galaxy (250+) fully visible it even becomes hard to click on a system, because the mouse cursor reacts so badly.
Have you turned off background starfields and galaxy gas, and tried enabling or disabling optimizing system rendering?
raptor wrote:The new largest offender is PartlyRoundedRect() at 14% of the whole, with most of that (10%) in CircleArc(), from CUIDrawUtil.cpp.
Those functions have a substantial number of immediate glVertex calls, so that's not surprising. This in particular, and most of the UI Wnd-derived classes, would be better re-implementing using buffer objects for rendering instead.

Post Reply