[Bf-viewport] [Bf-committers] blender2.8 branch being taken too lightly (imho)

[Brecht Van Lommel]

For better testing OpenGL changes, there's a regression testing script
here that compares screenshots between two Blender builds.
https://developer.blender.org/diffusion/BL/browse/trunk/lib/tests/opengl/test_regression.py

Running it on a few .blends after every compile, and on all
regressions .blends before committing saves a lot of time in my
experience, since any errors will be in the code you just changed. It
doesn't do timing currently but that's trivial to add.

On Thu, Feb 23, 2017 at 6:04 PM,  <blendergit at gmail.com> wrote:
> I can confirm Blender 2.8 is terribly slow on Windows 10.
>
>
>
> This makes very difficult to test your own code because you don’t know if
> the performance issue is related to your new code or not.
>
>
>
> Regards,
>
> Antonio
>
>
>
> De: Julian Eisel
> Enviado: jueves, 23 de febrero de 2017 15:15
> Para: bf-blender developers; bf-viewport at blender.org
> Asunto: Re: [Bf-committers] blender2.8 branch being taken too lightly (imho)
>
>
>
> Hi,
>
>
>
> I definitely agree here. I was actually planning to write a mail too.
>
> I am really concerned about the state of the 2.8 branch. Right now I'd
>
> consider it completely broken, I find it hard to do any dev work in
>
> it.
>
> While it's super cool to see so much process happening, I'm sure we're
>
> just shooting ourselves into the foot if we take feature quantity over
>
> quality.
>
>
>
> Here is a list of things that I'm worried about.
>
> * New collections/layers code breaks half of Blender. Only some parts
>
> of Blender have been converted to the new way we store objects and
>
> their data. IMHO, before any new collection/layer features are added,
>
> we should work on getting this fixed. It's not hard but really dirty
>
> work (I've actually done this before for GSOC, tell me about it!), but
>
> it has to be done.
>
> * API naming: Some new 2.8 code completely breaks consistency in
>
> API/function namings. E.g. with new Gawain code we have functions like
>
> add_attrib or immBegin called *a lot* throughout the entire code base.
>
> New collections/layers code is also pretty sloppy in it's own API
>
> namings (or maybe I just failed to see! ;) )
>
> * Compiler warnings: Lots of code has been committed with warnings
>
> that are easy to fix. Think in master we follow the policy to strictly
>
> avoid any new warnings (with default compiler flags), we should stick
>
> to it in blender2.8 too. We actually had real bugs in blender2.8 that
>
> went by unnoticed because warnings were hidden within the jungle of
>
> other harmless warnings. Right now I get about 300(!) warnings in new
>
> 2.8 code.
>
> * Code Style: Commits in blender2.8 handled this quite careless. We
>
> should all stick to our guidelines ([1]) for internal Blender modules.
>
> I recommend using our check_style_c.py script [2] for this.
>
>
>
> On top of that all, there is one issue, and I'm afraid it's a really
>
> major one by now: After various actions (like selecting objects),
>
> Blender gets incredibly slow here. This has been confirmed by others.
>
> It's an issue we've discussed many times before, but it's gotten
>
> *much* worse lately, to the point where a simple redraw for changed
>
> button highlights takes seconds. Also happens in release builds.
>
> To be fair, Mike investigated this in the past and added some great
>
> performance improvements for the new immediate mode code (good job
>
> nevertheless!). However, it seems like the actual issue is somewhere
>
> else.
>
> I'm afraid a big part of the 2.8 project will fail if we don't get
>
> this issue resolved. We can't deliver Blender like that so we had to
>
> revert all the OpenGL upgrade work. At least on OSX that would mean
>
> major 2.8 features like the new viewport wouldn't work until we're
>
> fully on OpenGL 3.2 core profile again.
>
>
>
> [1] https://wiki.blender.org/index.php/Dev:Doc/Code_Style
>
> [2]
> https://developer.blender.org/diffusion/BDT/browse/master/check_source/check_style_c.py
>
>
>
> Sorry for long mail </rant> ;)
>
> - Julian -
>
>
>
> On 23 February 2017 at 14:46, Ton Roosendaal <ton at blender.org> wrote:
>
>> Hi,
>
>>
>
>> No stepping toes here. Branches should just always work, especially the
>> ones more people work on together.
>
>> It's a good habit to never commit code that breaks things. And if that's
>> inevitable, align the other coders to help fixing it with highest priority.
>> Or ifdef things out.
>
>>
>
>> Luca: so, if yo notice someone committing code that breaks things, just
>> notify the person immediate. He/she is not meant to do this without general
>> approval.
>
>>
>
>> Laters,
>
>>
>
>> -Ton-
>
>>
>
>> --------------------------------------------------------
>
>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>
>> Chairman Blender Foundation, Director Blender Institute
>
>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>>
>
>>
>
>>
>
>>> On 23 Feb 2017, at 07:58, Luca Rood <dev at lucarood.com> wrote:
>
>>>
>
>>> Hey,
>
>>>
>
>>> I don't mean to cross any lines here, but I feel that this is important
>>> to be said.
>
>>>
>
>>> As far as I'm aware, the blender2.8 branch is supposed to replace master
>>> eventually, and much of the development has moved there already.
>
>>> Also, the word seems to be to keep blender2.8 stable, within reason.
>
>>>
>
>>> With that in mind, it seems logical to take just as much care of
>>> blender2.8 as master. This is one of our main development branches, and
>>> shouldn't be treated as lightly as one's personal branch or such.
>
>>>
>
>>> Despite that, and especially with the OpenGL immediate mode work going
>>> on, we continue getting commits that break Blender because of simple
>>> negligence.
>
>>> For instance, often the UI gets mangled, or we even get segfaults because
>>> of simple OpenGL mistakes, that could easily be avoided if the code was
>>> actually tested at all.
>
>>>
>
>>> I think everyone would appreciate it if we all tested our code before
>>> pushing it, to avoid at least the most obvious mistakes (a successful build
>>> does not always mean that stuff actually works :P ).
>
>>> So this is just a reminder for everyone to please test stuff before
>>> submitting (at least a little bit...)
>
>>>
>
>>> Again, I mean this just as a friendly observation :)
>
>>> If I'm wrong about my interpretation of the purpose of the blender2.8
>>> branch, please let me know.
>
>>>
>
>>> Happy coding,
>
>>>
>
>>> Luca
>
>>>
>
>>> _______________________________________________
>
>>> Bf-committers mailing list
>
>>> Bf-committers at blender.org
>
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>
>>
>
>> _______________________________________________
>
>> Bf-committers mailing list
>
>> Bf-committers at blender.org
>
>> https://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
>
> Bf-committers mailing list
>
> Bf-committers at blender.org
>
> https://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>