as someone who was a little frustrated with some of the changes from 0.6 to 1.0, and very happy about the lack of major changes (other than deprecations) so far from 1.0 to 2.0, I have couple of opinions, but I’d love to hear how the converge and contrast with other developers opinions:
migrate to c++17 - no more 10.7 brings us a lot of new language possibilities. it would be nice to know the percentage we’d be leaving behind, but I personally think the tradeoff will be worth it, regardless the statistics
float_8 will be very welcome
here’s where we might differ - let’s make it a breaking change, it will likely be a dramatic ui change and I think it’s worth it to have a breaking change for that
Can you elaborate on why you would want to make it a breaking change? When you say it would be worth making it a breaking change, what advantage that you know of would be gained by this? If the new drawing library has higher performance but developpers still have an option to use a nanovg wrapper (even if it’s slower), why would not offering the wrapper be an advantage?
(OT: I just read that C++ 20 is getting “modules”, although that probably doesn’t mean what I want it to mean! )
I don’t know the libraries proposed (Skia and vkvg) but I have a fever dream about using 3D drawing techniques (especially instancing) instead of drawing each widget separately like they were different (apart from position, scale and rotation or any predefined property that could be processed in a shader).
This could only help when having multiple modules from the same developer, using the same knobs, buttons, ports many times, but that isn’t so rare I think. One problem is that it would need the drawing to be done in a per plugin (and per widget) fashion (which is much uglier to implement than the current module based approach) and the more screen-like widgets would still need the current 2D procedural style rendering to function. Apart from these, it would get rid of some of the framebuffer/zoom-level related problems and it would also be a great step towards a 3D Rack
Sorry for going a bit off-topic. I otherwise like where Rack is heading, even if switching from nanovg will make me change a bunch of code.
Developers can be resistant to change and/or consider updating their code to use a new API as unnecessary work. If the wrapper layer is available, many developers might opt to just keep on using that instead of updating to the new API. Still, for practical intents and purposes, surely some kind of a wrapper has to be available so that all the existing code keeps working. (I wonder how many modules actually do use the nanovg functions directly, though? Maybe some kind of estimate could be done from the VCV library repos by searching for some common nanovg function names…)
Good Q. My guess is “more than you would think, but not a majority?” I can tell you of my 25 modules only one or two have a lot of custom drawing. But I certainly have a lot of semi-custom widgets that rely on “intermediate” objects like frame buffer and svg.
I know this is controversial, and many rack users are in the “I love 3D UI” camp, but there are of course people who don’t care for this much. I would be very reluctant to continue making modules if I were forced to make a 3D model of every widget. As I’m sure you know, in the “real world” (non VCV software) Skeuomorphism is seen as archaic, so an investment in learning how to do it won’t pay off much for those of us with “day jobs” programming. But I think you are suggesting that in your vision people could still make 2D UI if they want to, so a choice is fine.
almost all of my modules make use of it in some aspect.
skia, or whichever graphics library is chosen, will likely be a fairly big performance increase, even more than switching to nanovg-metal, and adding a wrapper layer for legacy nanovg would end up being a likely performance hit. for something this critical I’d accept a breaking change, but it really only helps if every module is moved over.
Yes, I meant drawing 2D widgets as sprites through instancing, no change in how things look. Actual 3D components would be just an optional next step (but I guess a lot of widgets can be extruded automatically and still look decent, like most ports and knobs). The amount of skeumorphism wouldn’t really change, I imagined keeping the flat shading as it is now. 3D Rack only interests me in terms of the possibility of going VR with it, I don’t see much gain in having for example a perspective camera render Rack on a 2D monitor, my main point is just to use the techniques that are usually used for 3D.
)