On Mo, 1.12.2014, 15:28, Timothy Reaves wrote:
> A rant it may be, but, accurate. Debug statements should never be made
> from a ‘production’ application, and your code added a LOT to what was
> already polluting system logs.
If you prefer an empty logfile, please #ifndef MAC_OSX away all
diagnostics and warnings. These are a few lines of extra messages, not
wrong initialisations.
I ask again: Does current trunk render correctly or not after you have
clicked away ("ignored") the warning panel? I am waiting for your simple
yes or no answer for days now. If all looks OK, the tests and warnings can
be removed from a Mac build.
I did not break anything, but try to make life easier for the team of
currently two regular Launchpad bug report referees, at the incredible
added burden of up to about four extra log lines on a *working* system,
intended to be visible in a few test builds before 0.13.2. And yes, 2-4 of
these can hopefully go away when string parsing is confirmed to work in
all cases, but I don't know how I should know how Intel and AMD (formerly
ATI) formatted their driver strings since 2006 (?) on all subvariants of
supported systems, so I am in fact expecting some string parsing errors by
self-assembled hardware and self-compiled operating systems unknown to me,
used by other people unknown to me, on other continents. If the program
tells the user what to do not only in a hidden logfile which some bug
reporters have not even found yet, but in an alert panel, we will
hopefully not get zillions more boring redundant bug report from
decade-old systems. This is an attempt to find out what is going on here
on all other operating systems, and ultimately find out what is really the
culprit that the GLSL1.10 shaders cause problems even for GLSL1.20 capable
systems.
> As to what I claim my Mac has, the nice thing about Macs is you don’t have
> to ‘claim’. It’s very well documented. Here is one such page:
> http://renderingpipeline.com/2012/06/mac-opengl-capabilities/
> <http://renderingpipeline.com/2012/06/mac-opengl-capabilities/> . You
> also don’t have to worry as to if a user has updated their driver, or is
> using the correct driver. Not an issue on a Mac.
Great, OpenGL3.2, not 4. Then why does the call glGetString(GL_VERSION)
deliver an answer from your OpenGL driver that basically says "This driver
supports OpenGL 2.1"? Such a message also appears on e.g. a Windows system
when drivers are old. The solution on a Windows or Linux or Ubuntu or
FreeBSD (or whatnot) system is to download and install new drivers, a.k.a.
update drivers, and then it reports OpenGL3 or better at this query if the
hardware is capable, and works. I don't know if I should be surprised if
Apple systems cannot be updated in a similar way, or if you just buy a new
Apple. On the other hand why would there be e.g.
http://www.macupdate.com/app/mac/49241/quadro-geforce-os-x-drivers
It may then be a Mac specific issue not found on the rest of computer
systems, which has been reported by you in a very unfriendly way not
earlier than last Friday.
> The current trunk reports that my machine is using 2.1 & GLSL 1.2, and
> then states this is not sufficient, and to upgrade my hardware and/or
> update my driver. This is clearly a defect. There really is no
> interpretation. This machine is a MacBook Pro (Retina, Mid 2012), and all
> Macs made in a very long time have supported - via driver - at least GL
> 3.2 which would be GLSL 3.2.
I ask again: Does current trunk RENDER correctly or not after you have
CLICKED AWAY the warning panel? I am waiting for your simple yes or no
answer for days now. If stars and planets look OK, the tests and warnings
can and should be removed from a Mac build, sure.
But the question remains why does glGetString(GL_VERSION) deliver an
answer from your alleged OpenGL3.2 system that says OpenGL2.1? This is a
call that I thought was independent from Qt and reports a system
component. http://www.macupdate.com/app/mac/17087/opengl-extensions-viewer
would give an independent diagnostic.
> I’ve created a branch where I specify the 4.2 driver, and then all of the
> shaders fail to compile, crashing the app. The #version XXX first line
> seems to be a requirement.
As I have already written, it is a requirement for code starting with GLSL
1.20. If the line is missing, it's compiled as GLSL1.10 for OpenGL, or as
GLSL ES 1.00 for OpenGL ES 2.00.
See these PDFs from the Khronos site:
The OpenGL® Shading Language
The OpenGL® ES Shading Language
> So I added the #version line, and changed the
> shaders so that they compile, but, not the app crashes for something not
> in our code; it seems to be in Qt, and when Alex tries this branch, his
> machine does not crash, but, just doesn’t render correctly.
>
> I’m more than will to try & solve this issue, but, as being largely
> ignorant of GL, and what exactly needs to be done to configure the Qt GL
> subsystem.
Does specifying version 4.2 work with the drivers reported as 3.2 on that
website? I guess not. Have you tested what kind of context/version/... you
received later?
When you indeed want to use some higher version like 3.2, there is this
relevant issue about initializeOpenGLfunctions() found in this year's Qt
blogs and docs. Stellarium currently runs circles around not deriving
rendering classes from QOpenGLFunctions as Qt recommends. Staying at
OpenGL2.1/OpenGL ES2.0 level is as I can see it an attempt to keep
compatibility with as many systems as possible as long as 3.2
functionality is not required. However the last months have shown that
also ANGLEs don't come as ultimate saviours for oldfashioned Windows
hardware (oldfashioned, not old. Yes my 2010 netbook has only lousy
OpenGL1.4), and systems not reporting OpenGL3/GLSL1.30/ps_3_0 in whichever
init strings are queried, are simply doomed to fail, at least on non-MacOS
X systems.
The OpenGL initialisation can be improved, no doubt. Qt5.4 brings another
round of changes and deprecates currently used classes. Somebody hopefully
finds time and has knowledge to put it all right again upto 5.4. Fighting
against testing and improving diagnostics is however no improvement
towards understanding what works or does not work.
BTW, this seems to be related: http://qt-project.org/forums/viewthread/20424
And now, apply this...
G.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Stellarium-pubdevel mailing list
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
