jdtournier
commented
6 years ago This is a response to this post:
@LeeReidCSIRO: I'm impressed (and pleasantly surprised) that you're interested in getting stuck into this. However, I have a feeling there's a slight misunderstanding as to how things would work. You suggest 3 tiers:
- data itself, with signalling properties
- properties of display of data, also with signalling properties
- display itself, listening to signals from other tiers
That's not really what I have in mind. I'll try to clarify.
I'm also envisaging 3 orthogonal components, but not those listed above:
-
Data and the associated state of the display. There would be no or minimal signalling - essentially all it needs to do is be able to request the scene be rendered again if anything has changed (very hard to do partial updates in OpenGL, you tend to redraw the whole scene). The important thing is that the data and its state can be modified independently of the other components, and the other components can be updated in response when notified of such change - but they don't have to. This means we can set up the scene (e.g. process all command-line options) before we even get an OpenGL context or initialise the GUI (important for off-screen rendering, for example). It would also be responsible for processing UI events such as mouse button presses, etc - but only in as far as it would provide suitable callbacks to handle the events, which (3) would then call as appropriate.
-
OpenGL renderer. This would render the data according to the state in (1). Importantly, this would contain only OpenGL commands, with no dependence on the GUI toolkit (i.e. Qt). This means we could ditch Qt altogether if we decide it's easier to perform offscreen rendering with e.g. glut. It would require a suitable OpenGL context be available and current by the time it performs the render (this would be the responsibility of the GUI toolkit), but would not be responsible for managing events, window resizes, button clicks, etc.
-
GUI toolkit (currently Qt). This would provide a suitable OpenGL context (whether on- or off-screen), present a UI around it, ensure it is in sync with the state in (1), pass mouse and keyboard events in the format expected by (1), etc. Note that this wouldn't even have to be a GUI at all - it could be a script interpreter for example. The main thing is it would allow manipulation of (1) and provide a context for (2) to operate.
The way I see this being implemented would require some very deep changes to the way the code is currently organised. Ideally, we'd probably have 3 folders, one for each of the layers above, and each mode / tool would have its own code within each of those. We could also have (1) & (2) merged together, so long as they remain logically separate (i.e. you can drive (1) without (2) having been initialised), but I reckon it would just be cleaner to keep them separate...
This is a huge refactor, and I wouldn't take it on lightly... We'd need new classes to represent the various parameters in (1) (in line with #1438. amongst other things), a system to keep track of whether a GL update is required that can be queried when necessary, a system to allow (1) to specify how it expects to be presented in the UI that (3) would then use to set itself up, new classes in (3) that would 'know about' the different types of parameter classes in (1) and display appropriate widgets for them, etc. It would require a lot of thought upfront to get the overall design vaguely right before we can start migrating the functionality over. Not trivial...
It would be great if you're interested in getting involved! Let me know if you want to dive in, we'd need to coordinate pretty tightly on this - I can be a bit of a control freak, but the last thing I want is to discourage others from contributing by constantly criticising their code and/or design decisions. But this shouldn't happen if we make sure we're on the same page from the outset. :+1:
LeeReid1
Just documenting this as #1403 prompted me to write down these ideas...
The current design of
mrviewis quite restrictive in many respects, which complicated things like offscreen rendering and scripting. This is two-fold:storage of rendering parameters in Qt widgets, rather than in a separate state object independent of Qt. This makes it near-impossible to set up an offscreen target, since the entire GUI front-end also needs to be initialised.
update of parameters within the
draw()call. This means that correct handling of command-line parameters requires that a GL update before the next option / command is processed to guarantee that operations happen in the correct order. This makes it impossible formrviewto process all options before rendering, needlessly re-rendering a potentially complex scene multiple times in the process.So I would like to (eventually) refactor the code to cleanly separate the state of the viewer, the OpenGL handling, and the Qt GUI parts. In particular, I would like to be able to manipulate the state of the render independently of the OpenGL handling, so that we can set up the view before any GL updates. I would also like to have all the code responsible for setting up the GUI widgets cleanly separated from the OpenGL handling. This would allow offscreen rendering to be implemented (potentially outside of Qt altogether), provide improved command-line / script handling, and hopefully also simplify maintenance (cleaner, more modular code).