Looks like this for me:

Sorry had ABP on...

In T53777#479139, @Joel Godin (FloridaJo) wrote:

@Pablo Vazquez (venomgfx) Is this yours Pablo?

@Pablo Vazquez (venomgfx) Is this yours Pablo?

If it happens again, please share a screen recording of the failed download (and ideally the output of the JS console).

Committed fix: rBO160cb91f8293fc295a523d42c3ba5091471ef4f5

I don't know if it's a good change, and I can't talk for the other guys. At least we should get @Pablo Vazquez (venomgfx)'s opinion, since he's the CSS master.

Ok, if you and Fsiddi think this is a good change I will modify the other repos that use the class.

Of course we'll accept good work! Half-done work, not so much, though ;-)

I do not think so but that would require more work that I did not want to do if this was not going to be accepted

Is there even a reason we should be using the image-rendering-crisp class if it's not setting crisp rendering?

This was resolved time ago. The tutorials page is monitored and updated regularly.

Fixed now. Thanks for the report!

There are quite some difficulties implementing email verification. Please refer to inbound configuration page of Phabricator documentation for more details.

Is there an issue that allows to confirm emails in Phabricator?

Inbound mail in Phabricator is somewhat unauthorized and we don't have facilities to constantly monitor spam activity in the developers resource.

Well, it is convenient to some degree. Roundup and GitHub support this and I suppose Bugzilla too. So, what is the rationale for disabling it?

This is intentional behavior, we do not recieve any email by the developer.b.o infrastructure.

The site was updated now, guess we can mark this one resolved! Thanks everyone :)

Hi Stanislav,

Thats valid for the current 2.7x series, soon for 2.8x, 3.2 will be the minimum. We should mention that on this page.

Looks good to me actually.

Guys! The problem is not in quantifying anything. I appreciate the discussion, but please let's return to the title of this report. The problem is that the system requirements page on blender.org:

The font issue usually has to do with quality settings in the driver set to performance instead of quality or so. So it is a driver issue.
The problem, as Campbell mentioned, is that you can't really quantify what "proper support" means. We try to be compliant to the OpenGL standard. However, drivers, even new ones, can be very particular in what they like OpenGL to do. So even newer GPUs can have glitches. For instance take T45117. What newer drivers have is better support, the driver teams still work on them. But this is a no brainer I hope. And in the end, it all depends on having the GPUs available for testing.
For 2.8 if we move to OpenGL 3.2 such requirements will be more enforcableI hope.

If it is indeed software implementation, as is stated on that page, would it give any benefit over simply running bundled Mesa with blender-softwaregl? Regardless, what users might do to improve their experience with Blender is beside the point of this report. This report is about (lack of) clarity of information on the blender.org site, not a particular issue of a particular Blender installation on a particular machine. As it is worded right now, users should expect the software to work without a hitch so long as their GPU supports OpenGL and is not an integrated one.

@Stanislav Blinov (radcapricorn):
Do you know that GeForce FX (5xxx) Series supported OpenGL 2.1 by the latest driver?
List of Nvidia graphics processing units

...And yet the screenshot in my first post was taken by a user in #blender on a machine with a GeForce 5700 FX LE (GL1.5). Cycles is selected as render engine, Solid shading mode, yet some objects are rendered completely white. As mentioned, same file opened by several people on newer cards didn't show the same issue. I understand that this particular case needs to go in a separate report, but that's not the first (or second, or tenth) time when people come in with similar problems.

Blender is functional on OpenGL 1.4 on a basic level, so its incorrect to say it doesn't work on OpenGL1.4 too.