Abstracting graphics operations into skins

As the title says, I come from a background where I created classes for the graphics calls, in that way they can be reused and swapped out.

I know this adds a tad bit more nesting but, most of the examples I see, people are doing the whole drawing in the Component, which is also acting as behavior and view.

So is there anything that shows other then just bench marking how a design like this might alter performance? Is it bad practice to encapsulate the Graphic drawing code for some reason?

Ok, I conceptualized this incorrectly, it’s basically just a strategy no nesting.

So pretty much other then memory, it shouldn’t make really any difference.

If you are wondering, what I had in my head is a Border class that can draw a Border with insets, animation etc. That is then added to a Component that needs a configurable border.

If this was the case then nesting could become an issue. Using a strategy to encapsulate this seems like it’s the way to go since I see no reason having to use a Component just to get a Graphic instance.(where I would need to in some other runtimes I have used)

I suggest you take a look at the tutorial here: https://docs.juce.com/master/tutorial_look_and_feel_customisation.html

The docs for juce::LookAndFeel can be found here.

1 Like

Thanks, it sometimes hard to wrap your head around all these different view implementations in various frameworks.

Ok, I was thinking themes did something else but it’s obvious a theme is what I just explained but not exactly.

A theme as I understood is a global configuration with components being styled/drawn.

I think my head cramp is just most graphics are just drawn through the API and not like I am used to. Bottom line is it seems I am mixing apples and oranges, thus confusing myself.