[Bf-committers] Blender roadmap article on code blog

[Campbell Barton]

On Wed, Jun 26, 2013 at 7:42 PM, David Jeske <davidj at gmail.com> wrote:
> On Tue, Jun 25, 2013 at 10:49 PM, Benjamin Tolputt <
> btolputt at internode.on.net> wrote:
>
>> > ...though now we have to define "integral". I would like to see more
>> > blender UI and experimental features built in a static-typed extension
>> > language like C#/Mono or TypeScript.
>>
>
>> I gotta say I neither want, agree, nor think this will ever happen.
>
> I understand, and you may be right. I'd like to respectfully share a few
> counter-points to your message...
>
>
>> For the latest Mac OSX version (i.e. the one I'd be running if I wasn't
>> building it myself) - that's 87MB. The latest stable Mono runtime is a
>> 103MB download - all by itself and without any of Blender packaged into it.
>>
>
> That 103MB Mono download size is not related to the embedded size as it
> includes all kinds of stuff that would not be included. One dev found that
> the embedded mono-runtime for his project was about
> 20MB<http://shishkin.wordpress.com/2009/12/24/mono-as-a-lightweight-net-runtime/>.
> Many of the libs he included are not needed for Blender, though the
> compiler would be needed because I want to compile directly from blender, I
> suspect 20-25MB is close. V8+TypeScript is much smaller then Mono or Python
> and is likely to remain so even as TypeScript matures, but with a loss of
> included module functionality.

Checking on the runtime size of these embeddable languages,
is typically not so large if you strip them down, so size alone isn't
argument against.

>> Secondly, and perhaps Campbell can speak to this, but I don't think type
>> safety is the largest source of bugs in Blender.
>
>
> I'm specifically talking about segfaults, and I think we are having a
> semantic issue. Type-validity, bounds-checking, and lack of direct pointer
> manipulation are all part of Type-Safety. By my view, nearly any segfault
> that occurs in C, other than failing to check a pointer for null, is
> ultimately a type-safety issue in someone's code.
>
> Of course a Type-Safe program can "crash" (aka, throw an Exception that
> can't be handled). However, that backtrace is a pretty good indication of
> where part of the problem lies. Wheras a segfault in C could be caused by
> any number of data-stomps unrelated to the call stack.

This seems like admitting defeat before identifying the problem,
as if you say --- "Blender crashes for me therefor you should use a
new language"

We should _really_ try to figure out what bugs you are running into
before leaping to conclusions.
Having dealt a lot with blender bugs I have my own opinions on this,
but these are also not backed up by facts/statistics
(in that respect something like break-pad would help for sure)...

But my own anecdotal experience is that areas of Blender can be made
very stable if developers focus on workflows/areas of the code -
running well,
but there are areas that fall under developers radars and users just
run into bugs --- grumble, and suffer crashes when these should be
getting fixed.

Its hard for us to know if your experience is caused by a few specific
bugs, or overall poor quality of code.
But we should try to find out before making assumptions.

One area I'm disappointed in Blender is with threading, in both Duran
and Mango we had to disable view-port redrawing during render because
of threading crashes, we just ran into too many hard to track down
bugs which ended up being related to Blender shooting its self in the
foot with threaded data access.

A few times I spent hours to track down the bugs and result was -
Blender is just had multiple threads accessing the same data (helgrind
is quite good at pointing these errors our, and while some of these
are harmless, enough are real bugs too).
We should just lock Blender while rendering & baking (any other
operation that depends on data not getting manipulated while it runs),
the benefit of being able to spin the 3d view around while rendering
is minimal compared to the problems it causes.

The fact you can crash Blender by toggling edit-mode while baking
vertex colors is ridiculous - try it!

...too many other ways to crash during bake to mention - but theres
nothing stopping you swapping out mesh data or converting the mesh to
a curve during bake.


>> Thirdly, type-safety in languages like C# & TypeScript comes with a
>> performance cost.
>
>
> Yes, there is a performance cost for Mono/V8 relative to C, but for many
> types of code that gap is quite small, about 1-3x
> slowdown<http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=csharp&lang2=gcc&data=u32>,
> shockingly Javascript-V8 is similar. Certainly smaller than CPython vs
> C's 30-50x
> slowdown<http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=gcc&data=u32>
> .
>
> I admit it's hard to predict what the slowdown would be for accessing
> DNA/RNA without trying it.

This can be made to work of course.

> A C#/Mono implementation is going to need a development environment setup
>> just like the current C/C++/Python setup does.
>>
>
> An Embedded C#/Mono environment would include a C# compiler in blender,
> just like Python's compiler is included in blender. Likewise for a
> V8/TypeScript environment. All the source could be included and users could
> edit/compile/run directly within blender, just like Python.. It would just
> be faster and static-typed.
>
>
>> There is a reason that most the third-party libraries used are written in
>> C/C++ and it's not just because it's the de facto coding language of the
>> OSS world.
>
>
> Well.. there are lots of reasons more third party libraries are written in
> C/C++. Those languages have been around longer. Integrating GC models is a
> "hard problem", so C/C++ offers the greatest flexibility for library code,
> since it can be imported into any runtime. And of course, when code is
> heavily leveraged, the work of expunging all pointer and bounds bugs is
> worth the effort for the performance gains.
>
> However, I don't think any of these arguments hold for new experimental
> blender features and UI. I personally would gladly give up 1-3x performance
> for new features to get no segfaults, simpler code, and the ability for any
> user to edit/compile/debug/patch that code within blender without
> setting-up a build system.

Read through your other comments, reasonable points but I would want
to be convinced the errors you hint at _can't_ be fixed first.

>> With all that in mind, it took me less than a hour to setup my build
>> environment both on Windows & on OSX (I already had the developer tools
>> installed).
>
>
> This evening I followed the steps to setup an OSX / XCode build, hoping to
> fix my list of retina bugs. A couple hours later I have a built-binary, but
> it crashes immediately on launch. I'm too unfamiliar with blender to have a
> clue what is causing it.

Crashes immediately is more likely to be some kind of build error (or
incompatible libs/environment) then a bug in the code.

This is bad, but also something that should be investigated - enough
devs use OSX successfully that this may just be some strange case you
managed to cause in your own setup.