Well, it took me a while to figure out where the rabbit went, but it looks like the folks at Kitware did build the "qt" driver in the standard way, linking it with rvu albeit in another directory. I don't remember the conversation on this, but it might have something to do with separability and keeping the C++ and Qt dependencies out of the main folders. The file qtrvu/qt.c handles the interface between rvu proper and the driver routines, which are all in C++.
I'd like to follow a similar strategy if we want to replace the Qt driver with something more native, rather than reproducing any of the non-driver sources in the rt directory for a Windows-ready edition of rvu. I don't have a problem including the new sources in the rt/ directory, though I'd prefer not adding too many new modules if we can avoid it. I think the rvu x11 driver is contained in 4 modules.
-Greg
···
From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 4:24:01 PM PDTI don't think I'm gonna touch (or even try to understand) that driver
business. On Windows, preview renderers have traditionally always been
native reimplementations of rvu. Rob is free to change that, of course...-schorsch
Am 2016-03-16 21:43, schrieb Gregory J. Ward:
While rvu can (and historically has) executed a driver as an
independent process, it is supposed to communicate with that driver
via a couple of pipes. I didn't realize that it handed over execution
to qtrvu. There is a "slave mode" that reverses operation, permitting
the display driver to call rvu as the parent process -- is that what
qtrvu is doing, or does it copy all the sources for rendering or call
the raycalls.c? I guess I should familiarize myself with that source
tree, but I've just been ignoring it up until now...
-GregFrom: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 1:10:33 PM PDT
I see three topics there:
Image viewer
Do we actually have another option for that on Windows?
What does OpenStudio use?
On a side note: The next Gimp version (3.10, currently in beta as
3.9.2) should be able to open HDR files. Though I suspect it will
not include the tonemapping algorithms or other analysis
functionality that we need here.
Second side note: I just saw that the NREL binary package still
has its image files as *.pic instead of *.hdr, is this deliberate?
Preview renderer
First I'll have to try and get Winrview running again...
Once we know it actually still works, I think Rob will be in the best
position to make a judgement on which one (or which combination) fits
the purpose best, and will be easier to grow more functionality with
in the future.
I never looked at that "driver/output device" mechanism very closely.
I think that in those cases where the "device" is actually a seperate
program, whichever rvu executable got invoked first with that option
will just hand over the job to its named sibling (that seems to be
how qtrview works on unix right now). Unless I'm missing some detail,
I don't think that will be a problem, even if there will probably be
only one device available on Windows for now.
Test suite unification
I think that one better goes into a seperate thread.
-schorsch