TextureGL and GUIFontTTFGL split and cleanup

[lrusak]

This splits the common GL and GLES classes into two separate classes. The thinking here is to have a common base and have GL/GLES specific stuff in their own class so we can avoid the #ifdef confusion. There is also some cleanup in regards to c-style casts and range based loops.

This will also make it easier in the future when GLES3 get's it's own classes.

There is still some other classes that can be split but that will be in a future PR.

I also seem to have a header loop which causes compiling issues and that's why some of the includes are laid out the way they are. If someone has ideas about how to improve that please let me know.

[yol]

Looks like a improvement to the status quo on first glance, but I'm not too deep into the GUI stuff - so let me ask a maybe stupid question: Why do we need the type aliases anyway? Can't this be solved with "regular" OO (inheritance/interfaces etc.)? I'm not saying that it's necessarily bad to do it like this, I'd just like to know why it is required.

[lrusak]

Looks like a improvement to the status quo on first glance, but I'm not too deep into the GUI stuff - so let me ask a maybe stupid question: Why do we need the type aliases anyway? Can't this be solved with "regular" OO (inheritance/interfaces etc.)? I'm not saying that it's necessarily bad to do it like this, I'd just like to know why it is required.

I agree, although I'm not sure exactly how to tackle this. Have a look at the questions I posted in slack. Then we can see how to proceed.

[FernetMenta]

It looks like you created a hierarchy with two abstract classes just for the single purpose of sharing code. In addition I see tricks like moving the original abstract methods of the base class (FirstBegin , LastEnd) from private to public. In order to understand the code one have to jump back and forth between three header and three body files.
The shared code between GL and GLES is just a snapshot of the current state and not an optimization of the actual behaviour. A change on the one or other end will most likely result in changes of those three classes.

[lrusak]

It looks like you created a hierarchy with two abstract classes just for the single purpose of sharing code. In addition I see tricks like moving the original abstract methods of the base class (FirstBegin , LastEnd) from private to public. In order to understand the code one have to jump back and forth between three header and three body files.

I don't really understand. Part of inheritance is sharing code is it not? With the purpose of abstracting different codes paths into a common interface. Also, FirstBegin and LastEnd were always public, I did not change that.

The shared code between GL and GLES is just a snapshot of the current state and not an optimization of the actual behaviour. A change on the one or other end will most likely result in changes of those three classes.

So it comes down to it again that you would rather have GL and GLES be completely separate? I mean how is that different than it is currently? Even if you would have to make a change that effects three classes it will still be more organized than it is now and you could even think of the current code being three classes all under the same class.

Regardless, something needs to be done here and if this isn't the correct way forward I'd like to discuss what is the ideal way forward. Using the static defines isn't nice but I'm not sure how to fix it. If you could explain in your mind how you think the best way to improve this code is please share.

We have three render systems which are all mutually exclusive so is there any benefit to having each GUITexture class have it's own name rather than just be called CGUITexture?

For the actual textures there is the possibility that more than one texture type can be used for a given rendering system. For now we have CTexturePi that is used in place of CTextureGL when they could be registered along side each other. I have also created a CTextureGBM class that could do the same thing. So I need some help with the architecture for how this should all fit together. 💭

[FernetMenta]

Also, FirstBegin and LastEnd were always public, I did not change that.

Take a closer look. You may not have changed this but this does not change the fact that it is a very bad design.

´´´
private:
virtual bool FirstBegin() = 0;
virtual void LastEnd() = 0;
´´´

So it comes down to it again that you would rather have GL and GLES be completely separate?

This is not what I said. Code sharing between architectures can be useful. The way it is done here can be improved.

We have three render systems which are all mutually exclusive so is there any benefit to having each GUITexture class have it's own name rather than just be called CGUITexture?

I don't know if you still have real headless on the roadmap. If this is done right the app would be able to switch from X11/OpenGL to Wayland/GLES for example. The current hacks won't allow this.

[Rechi]

This conflicts with using CTexture = CTextureGLES; in xbmc/guilib/TextureGLES.h

[afedchin]

magic number?

[phunkyfish]

@lrusak do you want to progress this, close it or put it on the backburner?

[lrusak]

I would still like to implement this. Something like this will need to be done if we ever want to implement the vulkan renderer.

[jenkins4kodi]

@lrusak this needs a rebase