Actually, I can even confirm that if I revert the HiDPI/QtQuick related changes to CanvasWidget.cxx and the ones introducing PUICamera.cxx (to make PUI optional during build time) , that FlightGear does again build properly using OSG 3.2.1 - note that these were all introduced at the beginning of October this year (i.e. when Dave reported them here), and these changes were announced as being a "PUI non-change, CanvasWidget appearance", given how things turned out over the course of the last 2 months, I am not sure that's a proper description to be honest - especially given that most people around here might not be able to simply revert such commits - as a matter of fact, let's keep in mind that Dave himself is a former FlightGear core developer, too, but still came here to report the problem.
https://sourceforge.net/p/flightgear/ma ... /36084254/
James wrote:Hi,
I just pushed a change which changes how we integrate PUI into the renderer and other systems; this makes our PUI usage more modular, so it can be enabled / disabled in a standard way. It also renders PUI via an FBO so we can use it safely (and scale it) on HiDPI screens, since PUI is too old to support a scaling factor as more modern UI toolkits would do.
I’ve done a fair amount of testing, and everything seems to be working, but if you see any changes in how PUI reacts to mouse or key presses, or the appearance of things, let me know. It’s using the same code as it always did but starting from a slightly different place, both in terms of drawing and event handling.
One temporary regression: right now CanvasWidget (the mechanism by which we include canvas content into PUI) is messed up because previously PUI had no alpha channel, so the canvas’s alpha was ignored. With the new system, the alpha is actually being used, but this is not really desired I think - it shows up as a semi-transparent map background in the ‘Select airport’ airfield chart, and in the Map-Canvas window at least. I thought I had a work-around for this, but the one I came up with is awkward to support on Windows, I need to think on a better solution, so in the meantime I pushed a hack so at least Windows still builds and runs.
(If your canvas content inside PUI has an opaque background, you’ll be fine, so one fix is just to adjust the Canvas code for those dialogs, but I’d like to find a backwards compatible fix)
Kind regards,
James
https://sourceforge.net/p/flightgear/ma ... /36084219/
James wrote:Steps to make PUI optional, HiDPI tolerant.
Move all PUI event and rendering into a custom camera, which can be
rendered via an FBO to account for display-resolution scaling (HiDPI).
Start wrapping PUI calls in #ifdefs so PUI can be disabled at compile
time; a run-time switch is trivial now but not implemented yet.
To be fair though, James seems to have anticipated the dilemma here:
https://sourceforge.net/p/flightgear/ma ... /35623408/
James wrote:while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.