Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Daniel J S. <dan...@ie...>]

On 01/07/2012 07:43 AM, Jérôme Lodewyck wrote:
> Hi,
>
> 	here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.

Thanks Jérôme.  From Mojca's comments, it sounds like this has addressed 
the major OS X issue of CoreFoundation access.  I've looked through the 
code and all seems straightforward.  I guess I like the fact that 
gnuplot_qt is now similar to the X11 terminal.  Did you have to do 
anything special with the communication channel?  Or did that just work 
out on its own?

...

Ethan/Jérôme, I have one comment about the hunk of code conditionally 
compiled into the program:

+#if QT_VERSION < 0x040700
+	/*
+	* FIXME: EAM Nov 2011
+	* It is better to use environmental variable
+	* QT_GRAPHICSSYSTEM but this requires qt >= 4.7
+	* "raster" is ~5x faster than "native" (default).
+	* Unfortunately "opengl" isn't recognized on my test systems :-(
+	*/
+	// This makes a huge difference to the speed of polygon rendering.
+	// Alternatives are "native", "raster", "opengl"
+	QApplication::setGraphicsSystem("raster");
+#endif

I'm wondering if instead of conditionally compiled code, whether maybe 
this would be better done as simple conditional code statements.  That 
way the binary would be portable across some compatible systems in which 
perhaps the only thing different is that one computer has a different Qt 
version than another.

There is an aboutQt() public function in the Qt utility:

http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#aboutQt

One could search the returned string for the version number and use that 
to conditionally call the setGraphicsSystem() function.  More than that, 
it might be nice if somehow one could get information from the Qt 
utility about the optional graphics selections.  (Anyone see how?)  That 
way one could select the most efficient graphics rendering and prioritize.

http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#setGraphicsSystem

I wonder if there might now be a fourth option, "openvg" which uses any 
available GPU.  Check this discussion:

http://juhaturunen.com/blog/2010/12/how-to-enable-hardware-accelerated-qml-rendering/

and

http://qtunderground.org/wiki/OpenVG

There is an interesting comment that "raster" is much slower than 
"openvg".  (And apparently Ethan found "raster" is faster than "native", 
which must really means something.)  So, with the EAM conditionally 
compiled code as it stands, "raster" is the best and only that the user 
will get.  Also, forcing "raster" as it does, there is no way to 
optionally control the choice with an environment variable.

So, I would think that the roll of this little hunk of code would be to 
achieve the greatest rendering speed, but not override any global 
environment settings for Qt.  How about something as follows

    get version from aboutQt
    if version >= Qt 4.5
       if QT_GRAPHICSSYSTEM does not exist
          pick highest rendering in order of
          "openvg", "opengl", "raster", "native"
       endif
    endif

How exactly to do the inner part, I'm not sure given no way of querying 
the Qt core.  Also, it'd be nice if setGraphicsSystem returned an error 
status, in which case one could try "openvg", if it fails try "opengl", 
if it fails try "raster".

Does this sound logical and easy to do?  If coded, is there someone with 
a GPU accelerated video card that could experiment with the 
QT_GRAPHICSSYSTEM environment variable to see how well this works.

...

One last item, once this has stabilized, check whether this line is 
necessary:

  		// Make sure the forked copy doesn't trash the history file
  		cancel_history();

Dan