Changes between Version 21 and Version 22 of Processing/lagdevelopersfaq


Ignore:
Timestamp:
Sep 4, 2013 5:33:51 PM (6 years ago)
Author:
besm
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Processing/lagdevelopersfaq

    v21 v22  
    379379#!div style="font-size: 100%"
    380380  {{{#!c++
    381   class Worker
    382   {
    383   public:
    384         Worker() : thread(0), stopped(false) {}
    385 
    386         virtual ~Worker()
    387         {
    388                 {
    389                         Glib::Mutex::Lock lock (mutex);
    390                         stopped = true;
    391                 }
    392                 if (thread)
    393                         thread->join();
    394         }
    395 
    396         void start()
    397         {
    398                 thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
    399         }
    400 
    401         Glib::Dispatcher sig_done;
    402 
    403   protected:
    404         virtual void run() = 0;
    405 
    406         Glib::Thread* thread;
    407         Glib::Mutex mutex;
    408         bool stopped;
    409   };
    410   }}}
    411 }}}
    412 
    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
     382{
     383public:
     384   Worker() :
     385      thread(0),
     386      stopped(false)
     387   {}
     388
     389   virtual ~Worker()
     390   {
     391      {
     392         Glib::Mutex::Lock lock (mutex);
     393         stopped = true;
     394      }
     395      this->join();
     396   }
     397
     398   void start()
     399   {
     400      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
     401   }
     402
     403   void join()
     404   {
     405      if (thread)
     406         thread->join();
     407      thread = 0;
     408   }
     409
     410   Glib::Dispatcher sig_done;
     411
     412protected:
     413   virtual void run() = 0;
     414
     415   Glib::Thread* thread;
     416   Glib::Mutex mutex;
     417   bool stopped;
     418};
     419  }}}
     420}}}
     421
     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:
    414423
    415424{{{
     
    430439}}}
    431440
     441Note that, in future, signal connects ought to be made when the program is starting, rather than during runtime.
     442
    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] ===
    468479
    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 [https://github.com/arsf/lag/issues?state=open issues page] currently in use as a rudimentary bug tracker.
    472481
    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.
     494
     495
     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.
    485497
    486498=== 5.5 What are some additional features that can be added to LAG? [=#q5.5] ===