Changes between Version 21 and Version 22 of Processing/lagdevelopersfaq

Timestamp:

Sep 4, 2013, 5:33:51 PM (11 years ago)

Author:

besm

Comment:

--

Processing/lagdevelopersfaq

@@ -379 +379 @@
 #!div style="font-size: 100%"
   {{{#!c++
-  class Worker
-  {
-  public:
-        Worker() : thread(0), stopped(false) {}
-
-        virtual ~Worker()
-        {
-                {
-                        Glib::Mutex::Lock lock (mutex);
-                        stopped = true;
-                }
-                if (thread)
-                        thread->join();
-        }
-
-        void start()
-        {
-                thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
-        }
-
-        Glib::Dispatcher sig_done;
-
-  protected:
-        virtual void run() = 0;
-
-        Glib::Thread* thread;
-        Glib::Mutex mutex;
-        bool stopped;
-  }; 
-  }}}
-}}}
-
-Each GUI class which uses threads has a {{{Worker}}} member initially set to null. Then once a function that starts the work is called the worker is created and started, and signal handlers are connected to handle the {{{Dispatcher}}} objects:
+class Worker
+{
+public:
+   Worker() :
+      thread(0),
+      stopped(false)
+   {}
+
+   virtual ~Worker()
+   {
+      {
+         Glib::Mutex::Lock lock (mutex);
+         stopped = true;
+      }
+      this->join();
+   }
+
+   void start()
+   {
+      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
+   }
+
+   void join()
+   {
+      if (thread)
+         thread->join();
+      thread = 0;
+   }
+
+   Glib::Dispatcher sig_done;
+
+protected:
+   virtual void run() = 0;
+
+   Glib::Thread* thread;
+   Glib::Mutex mutex;
+   bool stopped;
+};
+  }}}
+}}}
+
+Each GUI class which uses threads has a {{{Worker}}} member. Then once a function that starts the work is called the worker is started, and signal handlers are connected to handle the {{{Dispatcher}}} objects:
 
 {{{
@@ -430 +439 @@
 }}}
 
+Note that, in future, signal connects ought to be made when the program is starting, rather than during runtime.
+
 Once the worker has finished it emits {{{sig_done()}}} signal in its {{{run()}}} method notifying the caller class and {{{on_worker_work_finished()}}} method gets called. Most worker classes implement more signals to notify about different events (for example load progress to move the progress bar). The idea stays the same though. \\ \\
 Additionally in GUI classes {{{Glib::Mutex}}} objects are used at the beginning of each critical section to avoid race conditions. Using brackets around the section makes sure that the {{{Mutex::Lock}}} object gets automatically destroyed.
@@ -467 +478 @@
 === 5.2 What are the major issues with LAG that need fixing? [=#q5.2] ===
 
-Luckily there's not so many any more, however the major one is the memory consumption. This is quite a difficult problem, but it should be looked at before lag can be released to the public. \\ \\
-Another one is handling of the LAS 1.3 files, which works, but can be improved (eg. saving to the same file). This may not be possible though as long as laslib just ignores  full waveform data. \\ \\
-Also there is an issue with rendering/loading thread where forcing ON_EXPOSE event while loading a file at the same time may sometimes cause a segfault. For example moving some window on top of the TwoDeeOverview window while file is being loaded may cause this. This is most likely caused by both loading and rendering thread trying to access the quadtree at the same time and I believe sorting out the rendering thread should solve this problem.
+The github project has an [https://github.com/arsf/lag/issues?state=open issues page] currently in use as a rudimentary bug tracker. 
 
 === 5.3 What is lag memory issue? [=#q5.3] ===
@@ -483 +492 @@
 There's still plenty of refactoring to be done (possibly a good thing to start with to understand the code better). Particularly the rendering, which works, but is kind of scattered between different classes and methods and its threading which is just bad. Ideally there should be a separate Renderer/RenderingWorker class with all the code in one place. \\ \\
 Finally there is always some room for optimisations.
+
+
+Ultimately though, and this is a matter of opinion, someone needs to sit down and rethink how the GUI interacts with the gtkglext extensions and the backend. The logic managing the rendering is very mixed in with the rendering itself, and lots of control logic is mixed in with the code in the ui/ folder. Ideally the program could be separated into layers, where the mostly idle UI gives signals to a logical layer, which in turn translates these signals to fine operations on the graphical layer where rendering is being done concurrently, drawing from the threadsafe quadtree layer.
 
 === 5.5 What are some additional features that can be added to LAG? [=#q5.5] ===