Hello,
I wish the entire Rhino community a Merry Christmas with your families and a very prosperous New Year.!
And don’t forget that a program is of higher quality the more functions and tools it has with fewer KB…KB is like electronic bureaucracy, so to speak. You can see the attached table where I have noted the weight in KB of each version…You can see that there is a substantial increase from Rhino V4 to Rhino V 9 WiP.
An interesting assertion. That suggests that a program with 200 functions is better than one with 100, provided they are the same size. But suppose that the 200 functions are bug-ridden and the 100 are not. I would argue the 100 function program is the better, which is counter to your proposition.
Function density alone is not a sufficient measure of quality - indeed, it is probably well down the list of factors to consider.
Merry Christmas
Jeremy
Wait what is that even measuring? The space they take up in the Program Files folder? That doesn’t really mean anything, and that inflation would mostly have to with Windows…stuff. It’s also nothing compared to AAA video games, lol.
An interesting idea. Something to keep in mind when measuring the size of Rhino is that we have dependencies on the OS and languages we use which we can’t change. For example during Rhino 8 Mac we needed to bundle 2 builds, 1 for Intel and 1 for the new Apple M chips which added 100s of MBs to Rhinos size! But for Rhino 9, intel is being dropped by apple so we won’t include intel compatibility anymore and it drops down to what it was. Even without us changing or adding any features this would be the case.
There are some better approaches to reduce file size though:
I’m not sure where these ideas came from, I think AI? Apologies, but they all seem quite ill-informed. For example, As much as I love Rust, I’m not quite sure why the layers panel would benefit from being written in Rust?
Native C++ GUI’s tend to be the most solid and bug free. Nobody can do that anymore though.
Have patience and wait for Diwali, it symbolises the spiritual victory of Dharma over Adharma!
I would love to see Rhino rewritten in Holy C, the one true programming language.
Merry Christmas Team!
Cheers
DK
Not sure this graph is realistic but we should consider the additional library textures starting from V7 (or 6, not sure).
I’m not sure how you’re measuring things, but one can either subtract or add this whopper (for now):
There is some truth to it when we speak about RAM. But there this has little to do with the Installation size. Its not particular hard to generate GBs of RAM usage with a program of some KB on the harddisk.
But of course, with loading a lot of dynamic libraries into the memory there is a correlation to the size of installation. But the advantage of dynamic libaries is that you only need to load them, if you require them. Another part of a programs size depends on data (e.g. a texture) or 3rd party tooling (e.g. a Python distro), and this highly depends on the usecase.
You can trim applications dependencies to reduce the size. But this makes only sense if you have a usecase where it is expected that the user is not unintentionally trying to utilize the removed functionality. This is usually something you shouldn’t do if you provide scripting or addins.
Other than that some compilers allow you to optimize for size vs. performance. E.g. if you perform aggressive inlining, you copy code to prevent a function call. This slightly increases the performance in certain situations, but increases the binary size due to copied instructions.
And last but not least, the amount of “features” (I guess this is what you mean by “function”) doesn’t tell you anything about its complexity. Apart from low memory consumption and high performance, a professional software needs to be resilient, extentable and maintainable. You add significant amounts of code for abstractions, checks and error handling. In healthy portions, this is good bureaucracy if you will.
quite intriguingly ill informed may also be arguing against Rust which is a very powerful, performant and modern language that is steadily becoming a North Star on the horizon of software development, with big players like Microsoft mandating the move towards it leaving others like C/C++ behind while, yes, utilising AI.
the recent development of Rhino did not prove much to anything optimistic in UI and performance, much rather the opposite and since Rhino is quite a patchwork of code as far as i can tell, rewriting the entire thing can only make things faster more compact and easier to maintain. anyone who argues that it should stay like it is comes across super suspicious.
I’m quite confused by this reply, My post included that I love Rust? It’s my favourite language!
That being said, Rusts UI options are still newer and more limited → https://areweguiyet.com/, hence why I said I’m not sure why the Layers panel would benefit from being rewritten specifically in Rust.
rewriting any part of Rhino in a modern language would be interesting not only for performance purposes i assume, so writing anything to undermine even the idea thereof is confusing indeed.
there might be a reason why specifically layers, that is for @David53 to answer, still your replay was quite negative and hostile since “ill informed” is not a very approachable response. also AI is not your enemy. i understand that this is something that people love tossing around a lot these days, but using AI to substitute research or even develop should not be deemed bad by all means. time to embrace it, or in other words time to deal with it.
Dear friends,
I am very pleased that this topic is of interest to you, and I see that serious exponents of Rhino development are participating.
I am just a user, but I believe that simplicity in achieving objectives is the ultimate quality and, therefore, prestige. You shouldn’t need a supercomputer to create wonderful 2D and 3D shapes and give them beautiful tones thanks to a simple play of color, brightness, and opacity at an acceptable speed.
I have an old IBM ThinkPad and use Maxsurf without any problems. It is fast despite being a very complex program due to the calculations it performs, and it does not take up much space on the disk.
I would love for Rhino to be written in the same language. It would be fantastic, and even more so if there were a Maxsurf add-on in Rhino, all following the same finesse of the lines and graphics that currently exist in MaxSurf.
Maxsurf is written in C++.
Autocad is written in C++
It costs nothing to dream. 
Please tell me whether or not I am correct in this assessment.
The core of Rhino is written in C++
The choice of programming language or size of the delivered product is not the issue for your specific case. You have a very old GPU that doesn’t support many of the OpenGL features we use to draw geometry. We are switching to Direct3D in the Rhino 9 WIP to hopefully better support the very old GPUs, but in your case with such an old GPU there may not be much we can do. For others reading; I have tried supporting GdiGiro’s specific GPU over the years (I believe it is an Intel 2000 which came out in early 2011).
I think my very dry, mixed sense of humour has seriously backfired. I thought the suggestion of Assembly and the use of Holy C as a re-implementation would have led the way as to the degree of seriousness!
But on a serious note, the layers panel still seems to be one of the least responsive in Rhino 8; hence my specific targeting.
I am certainly not a real user of AI in any sense, at all. I used Dall-E a couple of times out of fascination, to infill backgrounds. But not for a good year or so. But I see its usefulness for some lighter refactoring and getting going.
Sorry I didn’t get this, I’m sure if I knew you better I’d have read it this way .
