yeah Perspex.ControlsBase doesn't sound too bad to me, good naming is always important! ;) However, what advantages do you think it would give? The reason for splitting stuff up into separate libraries was to prevent cross-layer dependencies but Perspex.Controls and Perspex.Controls.Base would be the same layer
despite the fact that i did it, i don't really like having multiple different assemblies, as it's not like one can be used without the other and it makes deployment more difficult as you can't just copy a single .dll
if there were a way to prevent x-layer dependencies in a single assembly we'd use that
but happy to hear arguments for Perspex.Controls.Base
My main argument is so that our markup data layer doesn't have a dependency on our concrete controls. I would prefer to have our markup to have no dependency on anything more than infrastructure, so splitting out control infrastructure from the concrete controls will ensure that we don't ever add that dependency.
Also, I remember seeing in one of the conversations that @grokys had in the Portable.Xaml repo about possibly supporting multiple markup formats (also present in our roadmap as a maybe). By keeping the markup orthogonal to the control infrastructure, we have a good example pre-built of not crossing different layers of abstraction.
Finished up, so here was my idea: If we were to do our NuGet packaging how Rx does (if we don't than this point is moot) having the separation would give us the framework/concrete split in terms of controls. Why would we do NuGet like Rx? One pro: people building plugins for Perspex could limit their dependencies to only the level of abstraction that their plugin requires. Con: have to manage multiple NuGet packages.
Awesome. I have not looked at this for a couple weeks now, but I think a new version of SkiaSharp was pushed that may have some of our needs (ie. DrawRoundedRect). Also @kekekeks may have some additional information, and he was going to look at the HW acceleration stuff