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 <schor...@schorsch.com> > Subject: Re: [Radiance-dev] Winrview and Winimage sources > Date: March 16, 2016 4:24:01 PM PDT > > I 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... >> -Greg >>> From: Georg Mischler <schor...@schorsch.com> >>> 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 _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
