Skip to content
Snippets Groups Projects
  1. Nov 12, 2021
  2. Nov 11, 2021
  3. Nov 10, 2021
  4. Nov 09, 2021
  5. Nov 08, 2021
    • Nat Goodspeed's avatar
      SL-16094: Zap thread safety land mine; thin PostMessage() calls. · 08336bb4
      Nat Goodspeed authored
      LLWindowWin32::mWndProc was a public WNDPROC member. If set non-NULL,
      mainWindowProc() would call that before falling into its own handler code. But
      now, mWndProc would be called on the window thread instead of on the main
      thread. Running arbitrary callback code on the window thread could cause all
      sorts of problems.
      
      It could be made safe by posting the callback call to the "mainloop" WorkQueue
      for execution on the main thread. But as no code actually references it,
      delete it instead.
      
      Per DaveP, the recent change to LLWindowsWin32Thread::post() could end up
      calling PostMessage() many times per frame, with nontrivial overhead.
      Reinstate the more selective code that calls PostMessage() with the dummy
      message (to bust us out of GetMessage() to check pending window-thread work
      requests) at most once per frame.
      08336bb4
  6. Nov 05, 2021
    • Nat Goodspeed's avatar
      SL-16094: Use ThreadPool for LLWindowWin32Thread. · c7af4921
      Nat Goodspeed authored
      Move the whole LLWindowWin32Thread class inside LLWindowWin32, and make it a
      struct. Migrate the struct declaration to llwindowwin32.cpp.
      
      Derive it from ThreadPool, which provides the WorkQueue. Use runPending()
      instead of manually popping and running individual queue items.
      
      Make its post() operation always PostMessage(bogus) whenever we put an entry
      in the WorkQueue, so we won't remain blocked in GetMessage().
      
      Instead of storing a back pointer to the LLWindowWin32 instance, store the
      relevant HWND and HDC in LLWindowWin32Thread itself to avoid cross-thread
      timing problems.
      
      Extract both instances of a large duplicated block of LLWindowWin32 code to a
      new recreateWindow() method, and call it in those places. Per the TODO, use a
      std::future to pass the new HWND and HDC back to LLWindowWin32 -- but also
      store them locally on the LLWindowWin32Thread instance.
      c7af4921
    • Nat Goodspeed's avatar
      SL-16202: Use WorkQueue::postTo() for texture create/post handshake. · ff549623
      Nat Goodspeed authored
      That is, when LLViewerFetchedTexture::scheduleCreateTexture() wants to call
      createTexture() on the LLImageGLThread, but postCreateTexture() on the main
      thread, use the "mainloop" WorkQueue to set up the handshake.
      
      Give ThreadPool a public virtual run() method so a subclass can override with
      desired behavior. This necessitates a virtual destructor. Add accessors for
      embedded WorkQueue (for post calls), ThreadPool name and width (in threads).
      
      Allow LLSimpleton::createInstance() to forward arguments to the subject
      constructor.
      
      Make LLImageGLThread an LLSimpleton - that abstraction didn't yet exist at the
      time LLImageGLThread was coded. Also derive from ThreadPool rather than
      LLThread. Make it a single-thread "pool" with a very large queue capacity.
      ff549623
    • Mnikolenko Productengine's avatar
    • Euclid Linden's avatar
      Merged in euclid-14098 (pull request #762) · 7cdaebae
      Euclid Linden authored
      SL-14098, enable occlusion culling during reflection pass
      
      Approved-by: Michael Pohoreski
      7cdaebae
  7. Nov 04, 2021
    • Dave Houlton's avatar
    • Dave Houlton's avatar
      SL-13565 occlusion/reflection tracy markup · 5e9351a4
      Dave Houlton authored
      5e9351a4
    • Nat Goodspeed's avatar
      SL-16202: Use large WorkQueue size limits for mainloop and General. · 834e7ca0
      Nat Goodspeed authored
      Give ThreadPool and WorkQueue the ability to override default
      ThreadSafeSchedule capacity.
      
      Instantiate "mainloop" WorkQueue and "General" ThreadPool with very large
      capacity because we never want to have to block trying to push to either.
      834e7ca0
    • Nat Goodspeed's avatar
      SL-16202: Streamline WorkQueues in LLImageGLThread. · d848d9e8
      Nat Goodspeed authored
      Use the new WorkQueue::postIfOpen() method in LLImageGLThread::post(). That
      makes the LLImageGLThread method a trivial wrapper, which can accept templated
      work items and pass them through to the WorkQueue method, eliminating double
      indirection due to multiple layers of std::function.
      
      Eliminate LLImageGLThread's WorkQueue intended for work on the main queue.
      Since the main loop already has a WorkQueue of its own, post work directly to
      that WorkQueue instead of using a separate WorkQueue misleadingly embedded in
      LLImageGLThread.
      
      Instead of looking up the main thread's WorkQueue every time, capture a
      pointer in LLImageGL's constructor.
      
      We no longer need a fallback queue for when the main thread's WorkQueue is
      full. We no longer need the main loop to poll LLImageGL to service the local
      main-thread-targeted WorkQueue, or to copy work from the fallback queue to the
      main queue. That eliminates LLImageGLThread::postCallback(), mCallbackQueue,
      mPendingCallbackQ, executeCallbacks() -- and even LLImageGL::updateClass() and
      LLAppViewer's call to it.
      
      Change LLViewerFetchedTexture::scheduleCreateTexture() to post work to the
      main thread's WorkQueue instead of calling LLImageGLThread::postCallback().
      d848d9e8
    • Nat Goodspeed's avatar
      SL-16202: Add postIfOpen() methods to WorkQueue, LLThreadSafeQueue. · 89f2169e
      Nat Goodspeed authored
      postIfOpen() provides a no-exception alternative to post(), which blocks if
      full but throws if closed. postIfOpen() likewise blocks if full, but returns
      true if able to post and false if the queue was closed.
      89f2169e
    • Nat Goodspeed's avatar
      SL-16202: Instantiate LLSimpleton::sInstance generically · 8458ad88
      Nat Goodspeed authored
      instead of requiring a separate declaration for each subclass.
      
      The previous way produces errors in clang.
      8458ad88
    • Nat Goodspeed's avatar
      7a5b9219
  8. Nov 01, 2021
  9. Oct 29, 2021
  10. Oct 28, 2021
  11. Oct 27, 2021
Loading