Re: [Bf-committers] proposal: OpenGL cleanup in master

[Martijn Berger]

Mesa supports opengl 3.3 in software. -> http://mesamatrix.net/

I think we should even consider just taking SandyBridge intel as baseline
-> http://www.g-truc.net/post-0729.html.

I agree with Brechts reasoning here and think we should do this now and in
master.





On Sun, Nov 22, 2015 at 11:13 AM, Bastien Montagne 
wrote:

> I’m not much an OGL guy, but fully support the proposal as well, think
> past attempts have shown trying to keep at all cost compatibility with
> very old standards just end up making evolution to modern ones
> impossible… Having a nine years old version as ground mandatory basis
> sounds totally reasonable. And afaik, MESA software is at least 100%
> implemented for OGL 3.3?
>
> Le 22/11/2015 03:11, Thomas Dinges a écrit :
> > I fully support this proposal, it's time to get work done and stop
> > worrying about ancient hardware.
> >
> > Am 22.11.2015 um 01:40 schrieb Mike Erwin:
> >> Cool, glad for the enthusiasm!
> >>
> >> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
> >> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
> >> software rendering for certain features but won't throw an error or
> catch
> >> on fire.
> >>
> >> That set of Radeons Brecht listed support up to GL 3.3 so should all
> work
> >> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> >> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
> >> wrote:
> >>
> >>> Yes, let's do it for 2.77. We are supposed to be able to break
> >>> compatibility now since we are transitioning to 2.8. I know people are
> >>> reluctant to drop compatibility because of the flak from a few users
> >>> with old hardware but we won't be able to do anything if we keep
> >>> postponing changes here.
> >>>
> >>> I suggest we make official final decision tomorrow in meeting. I hope
> >>> there is no more time needed to consider things here, this has been
> >>> discussed again and again during the last year and most people agree
> >>> with the change.
> >>>
> >>> Then it's GHOST patch time and finally everyone can start refactoring
> >>> code with shaders for fancy UI and display stuff :).
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[matmenu]

Very good idea but some questions:
The point to write in a master branch is to get a pretty sure 
integration and good testing. Couldn't this happen in the 2.8 branch if 
this one get's also a buildbot entry? 2.77 will most certainly be a long 
term release, I think it's better to let the whole current community 
profit from it. I for example program in the train on my way to work 
with an old eeePC with atom processor. Can't do any 3D work on it, but 
it's more than enough to program python addons.
If we are going to move to another OpenGL Version, why not take 4.4? All 
7 years (in 2016 for 2.77) old graphic card support it (AMD and Nvidia 
at least) https://de.wikipedia.org/wiki/ATI-Radeon-HD-5000-Serie and 
https://de.wikipedia.org/wiki/Nvidia-Geforce-400-Serie. I think 7 years 
old is good enough as it will most certainly stay like that for the 
whole 2.8 cycle so in the end, it will support 9 years old cards. 4 
years old Intel integrated cards all support 4.0 on windows, 4.1 on OS X 
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units. 
3.3 on Linux but maybe ask the community how many people will have a 
more than 4 years old integrated Intel GPU on exclusively Linux (no dual 
boot) in 2016? It would be sad to loose potential for 10 casual users 
who will most certainly be able to do everything they want with 2.77.
Regards
Mat

Am 22/11/2015 um 03:11 schrieb Thomas Dinges:
> I fully support this proposal, it's time to get work done and stop
> worrying about ancient hardware.
>
> Am 22.11.2015 um 01:40 schrieb Mike Erwin:
>> Cool, glad for the enthusiasm!
>>
>> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
>> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
>> software rendering for certain features but won't throw an error or catch
>> on fire.
>>
>> That set of Radeons Brecht listed support up to GL 3.3 so should all work
>> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
>>
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
>> wrote:
>>
>>> Yes, let's do it for 2.77. We are supposed to be able to break
>>> compatibility now since we are transitioning to 2.8. I know people are
>>> reluctant to drop compatibility because of the flak from a few users
>>> with old hardware but we won't be able to do anything if we keep
>>> postponing changes here.
>>>
>>> I suggest we make official final decision tomorrow in meeting. I hope
>>> there is no more time needed to consider things here, this has been
>>> discussed again and again during the last year and most people agree
>>> with the change.
>>>
>>> Then it's GHOST patch time and finally everyone can start refactoring
>>> code with shaders for fancy UI and display stuff :).
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Bastien Montagne]

I’m not much an OGL guy, but fully support the proposal as well, think 
past attempts have shown trying to keep at all cost compatibility with 
very old standards just end up making evolution to modern ones 
impossible… Having a nine years old version as ground mandatory basis 
sounds totally reasonable. And afaik, MESA software is at least 100% 
implemented for OGL 3.3?

Le 22/11/2015 03:11, Thomas Dinges a écrit :
> I fully support this proposal, it's time to get work done and stop
> worrying about ancient hardware.
>
> Am 22.11.2015 um 01:40 schrieb Mike Erwin:
>> Cool, glad for the enthusiasm!
>>
>> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
>> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
>> software rendering for certain features but won't throw an error or catch
>> on fire.
>>
>> That set of Radeons Brecht listed support up to GL 3.3 so should all work
>> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
>>
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
>> wrote:
>>
>>> Yes, let's do it for 2.77. We are supposed to be able to break
>>> compatibility now since we are transitioning to 2.8. I know people are
>>> reluctant to drop compatibility because of the flak from a few users
>>> with old hardware but we won't be able to do anything if we keep
>>> postponing changes here.
>>>
>>> I suggest we make official final decision tomorrow in meeting. I hope
>>> there is no more time needed to consider things here, this has been
>>> discussed again and again during the last year and most people agree
>>> with the change.
>>>
>>> Then it's GHOST patch time and finally everyone can start refactoring
>>> code with shaders for fancy UI and display stuff :).
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Mike Erwin]

Cool, glad for the enthusiasm!

It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
newer systems have GL 2.1 built in. Old low-end Macs might fall back to
software rendering for certain features but won't throw an error or catch
on fire.

That set of Radeons Brecht listed support up to GL 3.3 so should all work
in Blender 2.8 too! I'm not as familiar with nVidia's stuff.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
wrote:

> Yes, let's do it for 2.77. We are supposed to be able to break
> compatibility now since we are transitioning to 2.8. I know people are
> reluctant to drop compatibility because of the flak from a few users
> with old hardware but we won't be able to do anything if we keep
> postponing changes here.
>
> I suggest we make official final decision tomorrow in meeting. I hope
> there is no more time needed to consider things here, this has been
> discussed again and again during the last year and most people agree
> with the change.
>
> Then it's GHOST patch time and finally everyone can start refactoring
> code with shaders for fancy UI and display stuff :).
>
> On 21/11/2015, Brecht Van Lommel  wrote:
> > As I understand it, with OpenGL 2.1  the minimum requirements would be
> > effectively:
> >
> > * NVidia Geforce FX, Gerforce 6 and newer (released in 2003)
> > * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
> > * Intel HD graphics or newer (released in 2010), some older cards
> > might still work on OS X and Linux
> >
> > Mainly users with older Intel GMA graphics would be affected. That
> > sounds reasonable to me but we are raising the hardware bar for
> > Blender 2.77 then, right?
> >
> > I totally support doing this in master. Doing OpenGL refactoring in
> > big branches hasn't worked well in the past, better to do it
> > incrementally. I can help with some refactoring and code review.
> >
> > On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis 
> > wrote:
> >> You have my sword. And my axe. And my bow.
> >> I could trickle some free time on this, though not terribly much
> >> unfortunately.
> >>
> >> I definitely vote to do this on master/or current full dev branch (2.8
> >> branch?) when that changes. The previous approach of dumping chunks of
> >> code in a big branch that will code-rot as soon as time or energy
> >> dries out just does not work for such a big project in my opinion. We
> >> need an approach that will let us work on this incrementally.
> >>
> >> We should communicate well, with screams, on the street to
> >> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
> >> on blender.org, in the manual and with ugly message boxes with bright
> >> flashing red letters (OK, I admit that might be pushing it a little
> >> bit), especially for the windows and mac people, that system
> >> requirements are now raised to 2.1, and add the relevant checks and
> >> warnings in GHOST to ensure that people who try to use blender without
> >> it, cannot do so anymore. Current approach on Windows is just spawning
> >> a warning messagebox. We can leave that in but also quit blender in
> >> case it does not meet our requirements, and also expand to a similar
> >> approach for other OSs.
> >>
> >> On 21/11/2015, Mike Erwin  wrote:
> >>> Hi devs,
> >>>
> >>> I was responding to something in bf-viewport but could use a wider set
> >>> of
> >>> people to either agree or put a stop to this madness before it's too
> >>> late.
> >>> :)
> >>>
> >>> I'd like to start basic GL cleanup in master ASAP. By this I mean set
> GL
> >>> 2.1 as a baseline and convert all code that uses obsolete extensions to
> >>> the
> >>> functions/enums provided by GL itself. Much of this is simply deleting
> >>> ARB
> >>> or EXT, and removing checks for GL features that are guaranteed in 2.1.
> >>> No
> >>> new features, no major rewriting, just get the code up to spec and
> ready
> >>> to
> >>> branch for the bigger GL 3.2 upgrade.
> >>>
> >>> Staged migration of OpenGL:
> >>> now --> GL 2.1 (all platforms, soon)
> >>> --> 3.2 compatibility profile (Windows & Linux)
> >>> --> 3.2 core profile (all platforms, in time for Blender 2.8)
> >>>
> >>> That final transition will be the most work. The first transition can
> be
> >>> done NOW and doesn't involve any design really -- just a plan of what
> to
> >>> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop
> >>> will
> >>> let us clean up a lot of legacy crap without raising the hardware bar.
> >>>
> >>> Is anyone opposed to this? Anyone eager to help?
> >>>
> >>> Mike Erwin
> >>> musician, naturalist, pixel pusher, hacker extraordinaire
> >>> ___
> >>> Bf-committers mailing list
> >>> Bf-committers@blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >> 

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Thomas Dinges]

I fully support this proposal, it's time to get work done and stop 
worrying about ancient hardware.

Am 22.11.2015 um 01:40 schrieb Mike Erwin:
> Cool, glad for the enthusiasm!
>
> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
> software rendering for certain features but won't throw an error or catch
> on fire.
>
> That set of Radeons Brecht listed support up to GL 3.3 so should all work
> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
>
> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
> wrote:
>
>> Yes, let's do it for 2.77. We are supposed to be able to break
>> compatibility now since we are transitioning to 2.8. I know people are
>> reluctant to drop compatibility because of the flak from a few users
>> with old hardware but we won't be able to do anything if we keep
>> postponing changes here.
>>
>> I suggest we make official final decision tomorrow in meeting. I hope
>> there is no more time needed to consider things here, this has been
>> discussed again and again during the last year and most people agree
>> with the change.
>>
>> Then it's GHOST patch time and finally everyone can start refactoring
>> code with shaders for fancy UI and display stuff :).

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Antony Riakiotakis]

Yes, let's do it for 2.77. We are supposed to be able to break
compatibility now since we are transitioning to 2.8. I know people are
reluctant to drop compatibility because of the flak from a few users
with old hardware but we won't be able to do anything if we keep
postponing changes here.

I suggest we make official final decision tomorrow in meeting. I hope
there is no more time needed to consider things here, this has been
discussed again and again during the last year and most people agree
with the change.

Then it's GHOST patch time and finally everyone can start refactoring
code with shaders for fancy UI and display stuff :).

On 21/11/2015, Brecht Van Lommel  wrote:
> As I understand it, with OpenGL 2.1  the minimum requirements would be
> effectively:
>
> * NVidia Geforce FX, Gerforce 6 and newer (released in 2003)
> * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
> * Intel HD graphics or newer (released in 2010), some older cards
> might still work on OS X and Linux
>
> Mainly users with older Intel GMA graphics would be affected. That
> sounds reasonable to me but we are raising the hardware bar for
> Blender 2.77 then, right?
>
> I totally support doing this in master. Doing OpenGL refactoring in
> big branches hasn't worked well in the past, better to do it
> incrementally. I can help with some refactoring and code review.
>
> On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis 
> wrote:
>> You have my sword. And my axe. And my bow.
>> I could trickle some free time on this, though not terribly much
>> unfortunately.
>>
>> I definitely vote to do this on master/or current full dev branch (2.8
>> branch?) when that changes. The previous approach of dumping chunks of
>> code in a big branch that will code-rot as soon as time or energy
>> dries out just does not work for such a big project in my opinion. We
>> need an approach that will let us work on this incrementally.
>>
>> We should communicate well, with screams, on the street to
>> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
>> on blender.org, in the manual and with ugly message boxes with bright
>> flashing red letters (OK, I admit that might be pushing it a little
>> bit), especially for the windows and mac people, that system
>> requirements are now raised to 2.1, and add the relevant checks and
>> warnings in GHOST to ensure that people who try to use blender without
>> it, cannot do so anymore. Current approach on Windows is just spawning
>> a warning messagebox. We can leave that in but also quit blender in
>> case it does not meet our requirements, and also expand to a similar
>> approach for other OSs.
>>
>> On 21/11/2015, Mike Erwin  wrote:
>>> Hi devs,
>>>
>>> I was responding to something in bf-viewport but could use a wider set
>>> of
>>> people to either agree or put a stop to this madness before it's too
>>> late.
>>> :)
>>>
>>> I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
>>> 2.1 as a baseline and convert all code that uses obsolete extensions to
>>> the
>>> functions/enums provided by GL itself. Much of this is simply deleting
>>> ARB
>>> or EXT, and removing checks for GL features that are guaranteed in 2.1.
>>> No
>>> new features, no major rewriting, just get the code up to spec and ready
>>> to
>>> branch for the bigger GL 3.2 upgrade.
>>>
>>> Staged migration of OpenGL:
>>> now --> GL 2.1 (all platforms, soon)
>>> --> 3.2 compatibility profile (Windows & Linux)
>>> --> 3.2 core profile (all platforms, in time for Blender 2.8)
>>>
>>> That final transition will be the most work. The first transition can be
>>> done NOW and doesn't involve any design really -- just a plan of what to
>>> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop
>>> will
>>> let us clean up a lot of legacy crap without raising the hardware bar.
>>>
>>> Is anyone opposed to this? Anyone eager to help?
>>>
>>> Mike Erwin
>>> musician, naturalist, pixel pusher, hacker extraordinaire
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Campbell Barton]

Joining in with a +1 for moving to newer OpenGL version,
happy to help out with the upgrade too.

While it looks like we should be able to do this in master,
if this is causing changes all over with high chance of leaving master
in a broken state for some platforms,
it might be better to use a short-lived temporary branch (no longer
than one week).

As for the cleanup - is it enough to search code for known deprecated API use?
Or is there a way to trigger build-warnings or log-warnings at runtime?
Theres info on-line about this (lots of ways to do), if one works well
with Blender,
it'd be good to know.

On Sun, Nov 22, 2015 at 8:55 AM, Antony Riakiotakis  wrote:
> Yes, let's do it for 2.77. We are supposed to be able to break
> compatibility now since we are transitioning to 2.8. I know people are
> reluctant to drop compatibility because of the flak from a few users
> with old hardware but we won't be able to do anything if we keep
> postponing changes here.
>
> I suggest we make official final decision tomorrow in meeting. I hope
> there is no more time needed to consider things here, this has been
> discussed again and again during the last year and most people agree
> with the change.
>
> Then it's GHOST patch time and finally everyone can start refactoring
> code with shaders for fancy UI and display stuff :).
>
> On 21/11/2015, Brecht Van Lommel  wrote:
>> As I understand it, with OpenGL 2.1  the minimum requirements would be
>> effectively:
>>
>> * NVidia Geforce FX, Gerforce 6 and newer (released in 2003)
>> * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
>> * Intel HD graphics or newer (released in 2010), some older cards
>> might still work on OS X and Linux
>>
>> Mainly users with older Intel GMA graphics would be affected. That
>> sounds reasonable to me but we are raising the hardware bar for
>> Blender 2.77 then, right?
>>
>> I totally support doing this in master. Doing OpenGL refactoring in
>> big branches hasn't worked well in the past, better to do it
>> incrementally. I can help with some refactoring and code review.
>>
>> On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis 
>> wrote:
>>> You have my sword. And my axe. And my bow.
>>> I could trickle some free time on this, though not terribly much
>>> unfortunately.
>>>
>>> I definitely vote to do this on master/or current full dev branch (2.8
>>> branch?) when that changes. The previous approach of dumping chunks of
>>> code in a big branch that will code-rot as soon as time or energy
>>> dries out just does not work for such a big project in my opinion. We
>>> need an approach that will let us work on this incrementally.
>>>
>>> We should communicate well, with screams, on the street to
>>> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
>>> on blender.org, in the manual and with ugly message boxes with bright
>>> flashing red letters (OK, I admit that might be pushing it a little
>>> bit), especially for the windows and mac people, that system
>>> requirements are now raised to 2.1, and add the relevant checks and
>>> warnings in GHOST to ensure that people who try to use blender without
>>> it, cannot do so anymore. Current approach on Windows is just spawning
>>> a warning messagebox. We can leave that in but also quit blender in
>>> case it does not meet our requirements, and also expand to a similar
>>> approach for other OSs.
>>>
>>> On 21/11/2015, Mike Erwin  wrote:
 Hi devs,

 I was responding to something in bf-viewport but could use a wider set
 of
 people to either agree or put a stop to this madness before it's too
 late.
 :)

 I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
 2.1 as a baseline and convert all code that uses obsolete extensions to
 the
 functions/enums provided by GL itself. Much of this is simply deleting
 ARB
 or EXT, and removing checks for GL features that are guaranteed in 2.1.
 No
 new features, no major rewriting, just get the code up to spec and ready
 to
 branch for the bigger GL 3.2 upgrade.

 Staged migration of OpenGL:
 now --> GL 2.1 (all platforms, soon)
 --> 3.2 compatibility profile (Windows & Linux)
 --> 3.2 core profile (all platforms, in time for Blender 2.8)

 That final transition will be the most work. The first transition can be
 done NOW and doesn't involve any design really -- just a plan of what to
 remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop
 will
 let us clean up a lot of legacy crap without raising the hardware bar.

 Is anyone opposed to this? Anyone eager to help?

 Mike Erwin
 musician, naturalist, pixel pusher, hacker extraordinaire
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 

[Bf-committers] proposal: OpenGL cleanup in master

[Mike Erwin]

Hi devs,

I was responding to something in bf-viewport but could use a wider set of
people to either agree or put a stop to this madness before it's too late.
:)

I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
2.1 as a baseline and convert all code that uses obsolete extensions to the
functions/enums provided by GL itself. Much of this is simply deleting ARB
or EXT, and removing checks for GL features that are guaranteed in 2.1. No
new features, no major rewriting, just get the code up to spec and ready to
branch for the bigger GL 3.2 upgrade.

Staged migration of OpenGL:
now --> GL 2.1 (all platforms, soon)
--> 3.2 compatibility profile (Windows & Linux)
--> 3.2 core profile (all platforms, in time for Blender 2.8)

That final transition will be the most work. The first transition can be
done NOW and doesn't involve any design really -- just a plan of what to
remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop will
let us clean up a lot of legacy crap without raising the hardware bar.

Is anyone opposed to this? Anyone eager to help?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Antony Riakiotakis]

You have my sword. And my axe. And my bow.
I could trickle some free time on this, though not terribly much unfortunately.

I definitely vote to do this on master/or current full dev branch (2.8
branch?) when that changes. The previous approach of dumping chunks of
code in a big branch that will code-rot as soon as time or energy
dries out just does not work for such a big project in my opinion. We
need an approach that will let us work on this incrementally.

We should communicate well, with screams, on the street to
unsuspecting pedestrians and on the net to unsuspecting surfers, posts
on blender.org, in the manual and with ugly message boxes with bright
flashing red letters (OK, I admit that might be pushing it a little
bit), especially for the windows and mac people, that system
requirements are now raised to 2.1, and add the relevant checks and
warnings in GHOST to ensure that people who try to use blender without
it, cannot do so anymore. Current approach on Windows is just spawning
a warning messagebox. We can leave that in but also quit blender in
case it does not meet our requirements, and also expand to a similar
approach for other OSs.

On 21/11/2015, Mike Erwin  wrote:
> Hi devs,
>
> I was responding to something in bf-viewport but could use a wider set of
> people to either agree or put a stop to this madness before it's too late.
> :)
>
> I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
> 2.1 as a baseline and convert all code that uses obsolete extensions to the
> functions/enums provided by GL itself. Much of this is simply deleting ARB
> or EXT, and removing checks for GL features that are guaranteed in 2.1. No
> new features, no major rewriting, just get the code up to spec and ready to
> branch for the bigger GL 3.2 upgrade.
>
> Staged migration of OpenGL:
> now --> GL 2.1 (all platforms, soon)
> --> 3.2 compatibility profile (Windows & Linux)
> --> 3.2 core profile (all platforms, in time for Blender 2.8)
>
> That final transition will be the most work. The first transition can be
> done NOW and doesn't involve any design really -- just a plan of what to
> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop will
> let us clean up a lot of legacy crap without raising the hardware bar.
>
> Is anyone opposed to this? Anyone eager to help?
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers