Changes between Version 21 and Version 22 of Processing/lagdevelopersfaq

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



  • Processing/lagdevelopersfaq

    v21 v22  
    379379#!div style="font-size: 100%"
    380380  {{{#!c++
    381   class Worker
    382   {
    383   public:
    384         Worker() : thread(0), stopped(false) {}
    386         virtual ~Worker()
    387         {
    388                 {
    389                         Glib::Mutex::Lock lock (mutex);
    390                         stopped = true;
    391                 }
    392                 if (thread)
    393                         thread->join();
    394         }
    396         void start()
    397         {
    398                 thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
    399         }
    401         Glib::Dispatcher sig_done;
    403   protected:
    404         virtual void run() = 0;
    406         Glib::Thread* thread;
    407         Glib::Mutex mutex;
    408         bool stopped;
    409   };
    410   }}}
    411 }}}
    413 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:
     381class Worker
     384   Worker() :
     385      thread(0),
     386      stopped(false)
     387   {}
     389   virtual ~Worker()
     390   {
     391      {
     392         Glib::Mutex::Lock lock (mutex);
     393         stopped = true;
     394      }
     395      this->join();
     396   }
     398   void start()
     399   {
     400      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
     401   }
     403   void join()
     404   {
     405      if (thread)
     406         thread->join();
     407      thread = 0;
     408   }
     410   Glib::Dispatcher sig_done;
     413   virtual void run() = 0;
     415   Glib::Thread* thread;
     416   Glib::Mutex mutex;
     417   bool stopped;
     419  }}}
     422Each 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:
     441Note that, in future, signal connects ought to be made when the program is starting, rather than during runtime.
    432443Once 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. \\ \\
    433444Additionally 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.
    467478=== 5.2 What are the major issues with LAG that need fixing? [=#q5.2] ===
    469 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. \\ \\
    470 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. \\ \\
    471 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.
     480The github project has an [ issues page] currently in use as a rudimentary bug tracker.
    473482=== 5.3 What is lag memory issue? [=#q5.3] ===
    483492There'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. \\ \\
    484493Finally there is always some room for optimisations.
     496Ultimately 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.
    486498=== 5.5 What are some additional features that can be added to LAG? [=#q5.5] ===