1. 06 Nov, 2014 - 1 commit
    • Jocelyn Turcotte's avatar
      Fix a shutdown crash under CFAutoreleasePoolPop · ad518d95
      Jocelyn Turcotte authored
      
      NSAutoreleasePool init and dray must be symetrical and we can't guarantee
      that for ContentMainRunner as well as Chromium can since we initialize
      the ContentMainRunner on-demand but destroy it with the QCoreApplication's
      destruction.
      
      We also don't need to use it since any allocation that
      ContentMainRunnerImpl::autorelease_pool_ would cover is already covered
      at the bottom of the stack by the QCocoaAutoReleasePool in
      QCocoaEventDispatcher::processEvents.
      
      Change-Id: I2874916420457e3d36d08fb9fca0d919f374f592
      Reviewed-by: default avatarAndras Becsi <andras.becsi@digia.com>
      ad518d95
  2. 05 Nov, 2014 - 1 commit
  3. 29 Oct, 2014 - 2 commits
  4. 16 Oct, 2014 - 2 commits
  5. 14 Oct, 2014 - 1 commit
  6. 13 Oct, 2014 - 2 commits
  7. 03 Oct, 2014 - 2 commits
  8. 02 Oct, 2014 - 1 commit
  9. 26 Sep, 2014 - 2 commits
  10. 25 Sep, 2014 - 2 commits
  11. 24 Sep, 2014 - 2 commits
  12. 23 Sep, 2014 - 1 commit
  13. 22 Sep, 2014 - 1 commit
  14. 11 Sep, 2014 - 1 commit
    • Jocelyn Turcotte's avatar
      <tools/gyp> FIXUP: Allow letting qmake do the link step · e7cb808b
      Jocelyn Turcotte authored
      
      ld expects the -l switches to appear after the dependent object on
      the command line. It works if we use QT_PRIVATE to trigger Qt being
      added to the link line since it would be appended to LIBS_PRIVATE as
      well. But QT will append to LIBS, which is listed first in the
      Makefile and would cause undefined symbol errors by following .o
      files.
      
      Fix the issue by adding .o files to OBJECTS instead of LIBS_PRIVATE.
      This will only work if all Qt-dependent code is listed in the
      top-level gyp file, but we've been keeping it layered that way since
      the beginning and it should be acceptable to require it.
      
      Change-Id: I3b655ce8d6525fb986ca87fb9c2863a239ebf991
      Reviewed-by: default avatarAndras Becsi <andras.becsi@digia.com>
      e7cb808b
  15. 10 Sep, 2014 - 2 commits
  16. 05 Sep, 2014 - 1 commit
  17. 03 Sep, 2014 - 2 commits
  18. 02 Sep, 2014 - 1 commit
  19. 01 Sep, 2014 - 1 commit
    • Jocelyn Turcotte's avatar
      <chromium> Convert sync points to GL fence syncs. · 90056240
      Jocelyn Turcotte authored
      
      Chromium is always producing and consuming the textures on the GPU
      thread, switching the GL context accordingly, and are using sync
      points to externally know when it is correct to send the consumming
      GL commands down the pipe of their respective GL context.
      
      Since Qt is consuming those textures in a different thread,
      synchronizing when commands are handed down to GL isn't always enough.
      The GL driver could decide to do additional scheduling and end up
      executing Qt's consuming GL commands before Chromium's producing ones
      even if they were sent to their respective context in the right order.
      
      To prevent this, convert each sync point into a real GL fence sync
      and allow Qt to communicate the dependency between consuming and
      producing commands down to GL even across threads.
      
      gfx::GLFence can now be converted to a POD TransferableFence to allow
      waiting for or destroying the sync using a QOpenGLContext, which
      gl_fence.cc wouldn't be able to use through Chromium's GL function
      table.
      
      Change-Id: I8a9e2de6ed84b2e16f5504c5d66dc3580b87140a
      Reviewed-by: default avatarAndras Becsi <andras.becsi@digia.com>
      Reviewed-by: default avatarMichael Bruning <michael.bruning@digia.com>
      90056240
  20. 26 Aug, 2014 - 1 commit
  21. 22 Aug, 2014 - 1 commit
  22. 20 Aug, 2014 - 2 commits
  23. 18 Aug, 2014 - 1 commit
  24. 14 Aug, 2014 - 2 commits
  25. 12 Aug, 2014 - 5 commits