Marcel mdg
Hi all,
I would like to know if there are some basic rules to make your skin as lightweight as possible. For example I noticed the loading time for the standaard vdj performance skin is much faster than of the blocks skin.
Gr marcel
I would like to know if there are some basic rules to make your skin as lightweight as possible. For example I noticed the loading time for the standaard vdj performance skin is much faster than of the blocks skin.
Gr marcel
Posté Thu 14 Nov 24 @ 9:16 pm
locoDog
Use visibility as sparing as possible, always better to have a panel of several items with the panel having a single visibility condition rather than all the items having their own visibility if it's not needed.
panel groups also minimise visibility conditionals.
Skin makers over use variables for visibility, this is kind of an hold over from v7 skinning, the same thing can be done with panels on|off as they are saved and can be queried.
conditions save a lot of performance, conditions are like visibility but are only queried when a skin is loaded or reloaded, some skins don't use conditions and it hurts loading time. <pos> can be conditionally based to save lots of repeated xml code
Drawing elements over each other can add up to a less efficient skin.
Drawing elements in positions from scratch repeatedly is most of the time worse than predefining elements and calling it.
Placeholders are very confusing but very powerful for optimising performance and your writing speed. Used right you can send a placeholder thru several levels
Excessive options can slow a skin loading, most skin makers try to offer everything to everybody.
Each of these things on their own aren't that bad, even doing all these things a bit wouldn't hurt that much but they all add up.
No gold standard by any means, but my remix skin lines 7156 to 7544 how I drew the remix decks isn't bad, collapse the nodes shows some reasonably good practices, probably better to read from deck placement backwards to understand it.
but read top to bottom it goes like this
define a button leaning in to place holders
define a panel of those buttons, placeholders, some might be confirmed here for the smaller earlier things, some will be confirmed later up the chain, so placeholders for placeholders ( thing="[THING]" will eventually make sense )
define a panel with all the panels that make a deck
draw deck with conditional reference <pos> confirm any remaining place holders.
And truth be told, I could spend months optimising more, is it needed? not really, a skin that is easier to edit is usually better than something honed down to minimum chars / optimum, that takes 15 minutes just to remember/figure out how you did it in the first place.
Don't worry too much about optimum, what you're doing now is an achievement for now, a couple of weeks/months you'll thinking and working completely differently.
Get something simple made, it doesn't need to be your end idea or even finished.
I can see where you are and give you pointers.
panel groups also minimise visibility conditionals.
Skin makers over use variables for visibility, this is kind of an hold over from v7 skinning, the same thing can be done with panels on|off as they are saved and can be queried.
conditions save a lot of performance, conditions are like visibility but are only queried when a skin is loaded or reloaded, some skins don't use conditions and it hurts loading time. <pos> can be conditionally based to save lots of repeated xml code
Drawing elements over each other can add up to a less efficient skin.
Drawing elements in positions from scratch repeatedly is most of the time worse than predefining elements and calling it.
Placeholders are very confusing but very powerful for optimising performance and your writing speed. Used right you can send a placeholder thru several levels
Excessive options can slow a skin loading, most skin makers try to offer everything to everybody.
Each of these things on their own aren't that bad, even doing all these things a bit wouldn't hurt that much but they all add up.
No gold standard by any means, but my remix skin lines 7156 to 7544 how I drew the remix decks isn't bad, collapse the nodes shows some reasonably good practices, probably better to read from deck placement backwards to understand it.
but read top to bottom it goes like this
define a button leaning in to place holders
define a panel of those buttons, placeholders, some might be confirmed here for the smaller earlier things, some will be confirmed later up the chain, so placeholders for placeholders ( thing="[THING]" will eventually make sense )
define a panel with all the panels that make a deck
draw deck with conditional reference <pos> confirm any remaining place holders.
And truth be told, I could spend months optimising more, is it needed? not really, a skin that is easier to edit is usually better than something honed down to minimum chars / optimum, that takes 15 minutes just to remember/figure out how you did it in the first place.
Don't worry too much about optimum, what you're doing now is an achievement for now, a couple of weeks/months you'll thinking and working completely differently.
Get something simple made, it doesn't need to be your end idea or even finished.
I can see where you are and give you pointers.
Posté Thu 14 Nov 24 @ 11:08 pm
djdad
loading time of a skin doesnt mean that such a skin may cause performance issues.
You shouldn't care much about loading time.
As for performance, my rule at least, is to have smallest possible parts of the GUI that get refreshed constantly like waveforms, rotating jogs and texts that get frequently updated like the Times
Other than that, trust me no need to worry much.
You shouldn't care much about loading time.
As for performance, my rule at least, is to have smallest possible parts of the GUI that get refreshed constantly like waveforms, rotating jogs and texts that get frequently updated like the Times
Other than that, trust me no need to worry much.
Posté Fri 15 Nov 24 @ 1:47 pm