Curious about widget renderer system

Started by AdesII, 18 November 2016, 00:21:10

AdesII

Hi, i'm new in the forum and TGUI users community. I hope it will be a great journey with all of you.
I'm a real beginner ( less than 2 weeks ) so i beg for your tolerance :).

Actually, i'm here because i discovered the widget renderer system on late version ( unlike v0.6.10 ). I guess it's about optimising. I looked the source code but it's kind of confusing for me.

Maybe some people can explain me the main idea of this system ( i think it's about template, but i didn't get the link between renderer files [RendererDefines,WidgetRenderer]).

Thank you. And excuse my english, hope i'm clear in my request ahah !

AdesII


texus

#1
The goal of the renderers was to keep the logic code of a widget and the way it is displayed separate making the code a bit more modular.

It didn't entirely work out like planned. In 0.7 the rendering system was written and there was one renderer instance per widget. So basically the only use of the renderers was keeping the widget interface smaller (to change how the widget works there are functions that you call as widget->abc() while to change how the widget looks you call widget->getRenderer()->xyz()).

In 0.8-dev it got rewritten and the renderers are now shared between widgets. The renderers just store how you want the widget to look while the widget still does everything including drawing itself.

So there are 2 things you need to know about how they work:
1) They just contain the setters for when you want to change something. To change e.g. the text color of a button you can do button->getRenderer()->setTextColor(sf::Color::Red);
2) In 0.8-dev the renderers are shared between widgets. If you got the renderer from a theme, you can change how all the widgets look with a single function call to the renderer.

The RendererDefines is purely for internal use, they avoid too much copy-pasting in the code and the WidgetRenderer is the base class for all renderer classes, it contains the functions that you can call on any renderer.

AdesII

Well, thank you for your answer.

First of all don't worry about getRenderer(), we can see clearly how it works on the source code.
So, the point is about a better architecture, to implement easily. Great job !

You thought about this system because you found some issues in the old one ( wich was too rigid ? ) ?
Or just anticipated some futures features ?

You had this idea by your own, or by others ?

Keep going.
AdesII.





texus

I originally splitting them up to not have too much functions in the widgets (in some widgets there are more widgets for how the widget looks compared to functions for the logic part). Most of these renderer functions will probably never be used, especially since people will more likely load themes than manipulate a single widget renderer manually.

Just splitting it up like I did in tgui 0.7 lead to some bad code (both classes had to be friends to each other and were constantly accessing variables from each other). When I was considering reverting back I got into a discussion about it here: https://github.com/texus/TGUI/issues/45 (there is more text about the renderers than about the original topic).

For 0.8 I wanted the renderer to be independent of the widget itself. That discussion on github gave me some ideas on how to do it but what I have now in 0.8-dev is still very different from what was discussed there, but at least they are a lot less dependent on each other. The renderer is now independent of the widget, but at the cost of performance overhead and a widget that still contains almost all the code. The architecture isn't as good as I had hoped when I started splitting the class up but it is the best I can do for now. There are still some minor limitations (e.g. you can't change a property on the theme itself, you have to change the renderer of one button to change the way all the other buttons connected to that theme are drawn), but those are things that I still hope to improve before releasing 0.8 (which probably won't happen in the next 1-2 years anyway).