Open aolivier23 opened 6 years ago
aolivier23
commented
6 years ago Two strategies I am considering in parallel. I could either write my own openGL drawing area that works with gtkmm without using gdk to manage the openGL context, or I could switch to a new windowing library. This problem may also be correlated with how I plan to embed histograms in the mid-range future.
aolivier23
commented
6 years ago Currently working on solving this problem by migrating to IMGUI. Considered a multi-window GUI, but that seemed too complicated for my application. Also working on getting PUGL to work inside gtkmm, but ran into an opaque error from DRI when testing OpenGL rendering. Not sure where to go from this point with PUGL besides dissecting the code of something like GLFW.
aolivier23
commented
6 years ago Porting from gtkmm to Dear IMGUI is going very well, so I plan to release a version 2.0.0 that uses IMGUI instead of gtkmm. I am currently testing with GLFW providing an opengl window for the GUI + 3D visualization, but I am trying to minimize the number of places that depend on GLFW. Ideally, edepViewer will not depend on any particular system for setting up an opengl window.
I am trying to restore all of edepViewer's features to my IMGUI branch by the beginning of next week, but this might be a bit optimistic. I've got 3D visualization, basic event control, and a prototype list tree working on my feature branch. I want to use this feature branch in my regular work for a few weeks to at least find out about major bugs before pushing it to develop.
aolivier23
commented
5 years ago The IMGUI version of edepViewer turned out to cause problems on OS X at runtime because the main display window went unresponsive at a couple of points. The "obvious" solution to this problem seemed to be to do event processing in another thread, but the implementation turned out not to be so obvious. Serious refactoring and redesign of many components was needed, and it took me a few months to come up with and implement a working model.
v3.0.0 builds the latest multi-threaded edepViewer. The only time the window goes unresponsive on my test machine (Ubuntu 16.04) is the first time I run after a reboot when I haven't done anything with ROOT yet. I think this has to do with the ROOT version I have installed interpreting a bunch of objects the first time it is "initialized". v3.0.0 compiles with both gcc and Clang on Ubuntu 16.04 against edep-sim both before and after switching to private fields. So, please give it a try on OS X if you're interested in using edepViewer and let me know how it goes in this thread.
All event processing and file I/O happens in a separate thread now, and the GUI is supposed to be smart enough to wait for processing to finish if the user gets ahead. If the display does have to wait for processing to finish, the user should still be able to interact with the current event while waiting. This could mean that events with lots of energy deposits will now seem to load "instantly" after the first event because the conversion from edep-sim to a 3D model is done in parallel with user interaction. An as-yet-untested corollary of this is that events can be buffered over a bad internet connection through xrootd while the user is interacting with the first event. The event buffer is hard-coded to 5 at the moment (although I tested with a buffer size of 1000 to watch it fill up), but I'm planning to make that user-configurable in the near future.
edepViewer does not display the openGL window on OS X computers. I think XQuartz does not support openGL version > 2.1, so gtk has to run with the Quartz backend that is built on top of the Cocoa windowing system. gdk has only a non-implementation of Gdk::GLContext for the Quartz backend, so edepViewer crashes (politely) when run on OS X computers.