1. 02 May, 2017 1 commit
  2. 24 Jan, 2017 1 commit
  3. 23 Jan, 2017 1 commit
    • Julian Thijssen's avatar
      Add support for OpenGL 3.2+ core profile contexts in QPainter · 7dc88b68
      Julian Thijssen authored
      This change allows painting via QPainter onto a QOpenGLWindow, QOpenGLWidget
      or QOpenGLFramebufferObject when an core profile context is in use. This is
      important on macOS in particular, where compatibility profiles are not
      available, and so the only way to use modern OpenGL is via a core profile
      Added core profile compatible shaders with moder GLSL keywords.
      The paint engine binds a VAO and two VBOs from now on, whenever VAOs are
      supported. Note that this changes behavior also for OpenGL 2.x context that
      have VAO support via extensions.
      The Lancelot test suite gains support for core profile contexts. This can
      be triggered via -coreglbuffer in place of -glbuffer when manually inspecting
      via 'lance', while tst_lancelot will automatically run core context-based tests
      whenever supported.
      Task-number: QTBUG-33535
      Change-Id: I6323a7ea2aaa9e111651ebbffd3e40259c8e7a9c
      Reviewed-by: default avatarAllan Sandfeld Jensen <allan.jensen@qt.io>
  4. 18 Jan, 2017 1 commit
    • Laszlo Agocs's avatar
      Remove OpenGL dependency from qTriangulate · 8c144298
      Laszlo Agocs authored
      The original implementation is only suitable as long as the only client
      is the GL paint engine which will call the function with the GL context
      current. In other cases this cannot be ensured. For instance, doing
      triangulation on the gui thread in a Quick application using the threaded
      render loop will have to deal with not having a current context on that
      thread at all. Doing triangulation on worker threads has the same problem
      as well.
      In addition, in modern Qt versions a -no-opengl build does not imply no
      accelerated graphics API.
      Therefore, drop the ElementIndexUint check from qtriangulator.cpp and leave
      it up to the caller to tell if uint indices are supported or not.
      Change-Id: I7491d84981ee22d05c5fde08994dbb3a4e2432e9
      Reviewed-by: default avatarGunnar Sletta <gunnar@crimson.no>
  5. 28 Feb, 2016 1 commit
  6. 21 Jan, 2016 1 commit
  7. 15 Jan, 2016 1 commit
  8. 19 Oct, 2015 1 commit
  9. 12 Mar, 2015 1 commit
  10. 26 Feb, 2015 1 commit
  11. 16 Feb, 2015 1 commit
    • Allan Sandfeld Jensen's avatar
      Use C++ <cmath> instead of <math.h> · 515e802a
      Allan Sandfeld Jensen authored
      Including math.h can pollute the default namespace, and break
      some compilers if cmath versions of the method are declared as using.
      Switching to C++ math functions also greatly simplifies handling of
      float qreal as C++ automatically chooses the right method.
      [ChangeLog][QtCore][QtMath] qmath.h no longer includes math.h, so any
      sources depending on that indirect inclusion may fail to build.
      Change-Id: I4d0e331dafba354ec05dc5052e61ef4ff8d387fe
      Reviewed-by: default avatarRafael Roquetto <rafael.roquetto@kdab.com>
  12. 11 Feb, 2015 1 commit
    • Jani Heikkinen's avatar
      Update copyright headers · 83a5694d
      Jani Heikkinen authored
      Qt copyrights are now in The Qt Company, so we could update the source
      code headers accordingly. In the same go we should also fix the links to
      point to qt.io.
      Outdated header.LGPL removed (use header.LGPL21 instead)
      Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
      combination. New header.LGPL-COMM taken in the use file which were
      using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
      Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
      Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
      Reviewed-by: default avatarMatti Paaso <matti.paaso@theqtcompany.com>
  13. 14 Dec, 2014 2 commits
  14. 13 Dec, 2014 1 commit
    • Tor Arne Vestbø's avatar
      Ensure that GL::updateBrushTexture() activates and binds properly · dfccd78a
      Tor Arne Vestbø authored
      Calling QOpenGL2GradientCache::getBuffer() will generate the texture the
      first time, calling glBindTexture in the process. We did this without
      first ensuring that the right texture unit was active, resulting in the
      generated gradient texture binding onto the glyph cache mask unit.
      We now provide a specialization of bindTexture for a QGradient, which
      ensures that the right unit is active before calling getBuffer().
      Unfortunately we have no way of knowing if the result of getBuffer()
      was a texture that was already bound, or if we need to bind the result,
      which means we have to do an unconditional bindTexture of the resulting
      texture ID. This means double-bind for the initial texture generation,
      but this was already an issue in the original code.
      Task-number: QTBUG-43039
      Task-number: QTBUG-41244
      Change-Id: I20c9b795c8c14f8d58be2b60a284c5a060705ec0
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@theqtcompany.com>
      Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
  15. 12 Dec, 2014 1 commit
  16. 11 Dec, 2014 1 commit
  17. 10 Dec, 2014 1 commit
    • Tor Arne Vestbø's avatar
      GL2PaintEngine: Prevent fillInPendingGlyphs from breaking gradients · e9222e19
      Tor Arne Vestbø authored
      The glyph cache internally uses the image texture unit when blitting,
      but doesn't always activate the unit before binding its texture,
      resulting in sometimes binding the glyph cache texture to the
      wrong unit.
      The image texture unit is also the same as the brush texture unit,
      so any time we fill in pending glyphs we need to re-bind the brush
      texture, otherwise drawing text with eg. gradients will fail after
      the new glyphs have been filled.
      The new hasPendingGlyphs() member function of the glyph cache
      is an optimization so that we don't need to activate and rebind
      unless there are glyphs that need to be filled.
      Change-Id: Iac74130145d2d6d7bf95206b5e8a2fc760743cb5
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@theqtcompany.com>
      Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
  18. 05 Dec, 2014 1 commit
  19. 04 Dec, 2014 1 commit
  20. 03 Dec, 2014 1 commit
  21. 27 Oct, 2014 1 commit
  22. 16 Oct, 2014 1 commit
  23. 14 Oct, 2014 1 commit
    • Laszlo Agocs's avatar
      Fix QOpenGLWidget on Cocoa when used as viewport · ebc835c2
      Laszlo Agocs authored
      Having a QOpenGLWidget as a graphics view viewport was not functioning
      on OS X: it was showing incomplete content due to accessing the texture
      attached to the framebuffer object before the rendering is complete.
      On the normal path, when rendering is done via paintGL(), the flush was
      there. When used as a viewport however, this path is not used. The missing
      flush is now added for the other case too. For performance reasons, we will
      not flush on every paint engine end(). Instead, the flush is deferred until
      composition starts.
      QGLWidget also featured a weird on-by-default autoFillBackground concept. To
      maintain compatibility with apps that used QGLWidget as the viewport for
      QGraphicsView, we will now do the same for QOpenGLWidget, but only when it
      is used as a viewport. For regular QOpenGLWidgets autoFillBackground defaults
      to false, like for any other widget. The docs are extended with a small section
      about differences between QGLWidget and QOpenGLWidget.
      Task-number: QTBUG-41046
      Change-Id: I42c2033fdd2ef5815783fd640fe11373761061e0
      Reviewed-by: default avatarJørgen Lind <jorgen.lind@digia.com>
  24. 24 Sep, 2014 1 commit
  25. 23 Sep, 2014 1 commit
  26. 09 Aug, 2014 1 commit
  27. 01 Aug, 2014 1 commit
    • Laszlo Agocs's avatar
      Make QOpenGLWidget public · e453484b
      Laszlo Agocs authored
      QOpenGLWidget is now public.
      In addition Qt::WA_AlwaysStackOnTop is introduced to support the
      special case of semi-transparent QOpenGLWidget or QQuickWidget on
      top of regular widgets.
      hellogl_es2 becomes the qopenglwidget example. This example performs
      painting both via QPainter and native GL commands and has the OpenGL
      widget combined with other, normal widgets.
      The widget stack receives some changes when it comes to renderToTexture
      widgets like QQuickWidget and QOpenGLWidget. Calling update() will now
      result in a paint event, which is essential for QOpenGLWidget since we
      want it to behave like a regular widget. The dirty region handling is
      extended specially for such widgets due to performance reasons.
      (an OpenGL content update must not result in any backingstore painting,
      and is thus handled as a different kind of dirtiness)
      [ChangeLog] Added QOpenGLWidget. This widget serves as a replacement for QGLWidget.
      Task-number: QTBUG-36899
      Task-number: QTBUG-40086
      Change-Id: Ibf7f82fea99b39edfffd2fc088e7e0eadbca25cf
      Reviewed-by: default avatarPaul Olav Tvete <paul.tvete@digia.com>
  28. 04 Jul, 2014 1 commit
    • Allan Sandfeld Jensen's avatar
      Make QOpenGLTextureCache::bindTexture upload efficiently · 8a031696
      Allan Sandfeld Jensen authored
      Currently QOpenGLTextureCache::bindTexture always convert any uploaded
      image to RGBA8888 before uploading. This is quite inefficient when
      OpenGL natively supports uploading formats in the original format.
      This patch adds support for uploading a few native QImage formats. This
      also get the performance of QOpenGLTextureCache::bindTexture on par with
      The texture brush used by QOpenGLPaintEngine is also converted to QImage,
      since bindTexture will convert it to QImage anyway, and going over QPixmap
      may cause an unnecessary conversion.
      [ChangeLog][QtGui][QOpenGLTextureCache] Support uploading common QImage
      formats directly to OpenGL when supported.
      Change-Id: I828a763126441a98e4547c32ef52dddf7c129a32
      Reviewed-by: default avatarGunnar Sletta <gunnar.sletta@jollamobile.com>
  29. 25 Apr, 2014 1 commit
    • Laszlo Agocs's avatar
      Rename new QOpenGLContext APIs · f9d32327
      Laszlo Agocs authored
      isES() becomes isOpenGLES(). The library type enums are changed
      DesktopGL -> LibGL and GLES2 -> LibGLES. This removes the now
      unnecessary version number, the confusing "desktop" term and provides
      better readability.
      The old function/values are kept until the related qtdeclarative
      changes are integrated.
      Task-number: QTBUG-38564
      Change-Id: Ibb0a1209985f1ce4bb9451f9b7b093c2b68a6505
      Reviewed-by: default avatarSean Harmer <sean.harmer@kdab.com>
  30. 10 Mar, 2014 1 commit
  31. 04 Mar, 2014 1 commit
    • Laszlo Agocs's avatar
      Dynamic GL: remove exporting symbols · 4b2f35d0
      Laszlo Agocs authored
      Remove the opengl proxy for now. Later it will either be moved into
      a separate library or replaced by a QOpenGLFunctions-based approach.
      This means that the -opengl dynamic configuration is not usable
      for the time being. The rest of the enablers remain in place.
      The convenience function QOpenGLFunctions::isES() is now moved to
      QOpenGLContext and is changed to check the renderable type. This is
      extremely useful since besides supporting dynamic GL it solves also
      the problem of GL_ARB_ES2_compatibility (i.e. it triggers the real ES
      path when creating an ES-compatible context with a desktop OpenGL
      Task-number: QTBUG-36483
      Task-number: QTBUG-37172
      Change-Id: I045be3fc16e9043e1528cf48e6bf0903da4fa7ca
      Reviewed-by: default avatarFriedemann Kleint <Friedemann.Kleint@digia.com>
      Reviewed-by: default avatarJørgen Lind <jorgen.lind@digia.com>
  32. 19 Feb, 2014 1 commit
  33. 17 Feb, 2014 1 commit
  34. 14 Feb, 2014 1 commit
    • Laszlo Agocs's avatar
      Dynamic GL switch on Windows · 97c187da
      Laszlo Agocs authored
      The patch introduces a new build configuration on Windows which
      can be requested by passing -opengl dynamic to configure.
      Platforms other than Windows (including WinRT) are not affected.
      The existing Angle and desktop configurations are not affected.
      These continue to function as before and Angle remains the default.
      In the future, when all modules have added support for the dynamic
      path, as described below, the default configuration could be changed
      to be the dynamic one. This would allow providing a single set of
      binaries in the official builds instead of the current two.
      When requesting dynamic GL, Angle is built but QT_OPENGL_ES[_2] are
      never defined. Instead, the code path that has traditionally been
      desktop GL only becomes the dynamic path that has to do runtime
      checks. Qt modules and applications are not linked to opengl32.dll or
      libegl/glesv2.dll in this case. Instead, QtGui exports all necessary
      egl/egl/gl functions which will, under the hood, forward all requests
      to a dynamically loaded EGL/WGL/GL implementation.
      Porting guide (better said, changes needed to prepare your code to
      work with dynamic GL builds when the fallback to Angle is utilized):
      1. In !QT_OPENGL_ES[_2] code branches use QOpenGLFunctions::isES() to
      differentiate between desktop and ES where needed. Keep in mind that
      it is the desktop GL header (plus qopenglext.h) that is included,
      not the GLES one.
      QtGui's proxy will handle some differences, for example calling
      glClearDepth will route to glClearDepthf when needed. The built-in
      eglGetProcAddress is able to retrieve pointers for standard GLES2
      functions too so code resolving OpenGL 2 functions will function
      in any case.
      2. QT_CONFIG will contain "opengl" and "dynamicgl" in dynamic builds,
      but never "angle" or "opengles2".
      3. The preprocessor define QT_OPENGL_DYNAMIC is also available in
      dynamic builds. The usage of this is strongly discouraged and should
      not be needed anywhere except for QtGui and the platform plugin.
      4. Code in need of the library handle can use
      The decision on which library to load is currently based on a simple
      test that creates a dummy window/context and tries to resolve an
      OpenGL 2 function. If this fails, it goes for Angle. This seems to work
      well on Win7 PCs for example that do not have proper graphics drivers
      providing OpenGL installed but are D3D9 capable using the default drivers.
      Setting QT_OPENGL to desktop or angle skips the test and forces
      usage of the given GL. There are also two new application attributes
      that could be used for the same purpose.
      If Angle is requested but the libraries are not present, desktop is
      tried. If desktop is requested, or if angle is requested but nothing
      works, the EGL/WGL functions will still be callable but will return 0.
      This conveniently means that eglInitialize() and such will report a failure.
      Debug messages can be enabled by setting QT_OPENGLPROXY_DEBUG. This will
      tell which implementation is chosen.
      The textures example application is ported to OpenGL 2, the GL 1
      code path is removed.
      [ChangeLog][QtGui] Qt builds on Windows can now be configured for
      dynamic loading of the OpenGL implementation. This can be requested
      by passing -opengl dynamic to configure. In this mode no modules will
      link to opengl32.dll or Angle's libegl/libglesv2. Instead, QtGui will
      dynamically choose between desktop and Angle during the first GL/EGL/WGL
      call. This allows deploying applications with a single set of Qt libraries
      with the ability of transparently falling back to Angle in case the
      opengl32.dll is not suitable, due to missing graphics drivers for example.
      Task-number: QTBUG-36483
      Change-Id: I716fdebbf60b355b7d9ef57d1e069eef366b4ab9
      Reviewed-by: default avatarFriedemann Kleint <Friedemann.Kleint@digia.com>
      Reviewed-by: default avatarJørgen Lind <jorgen.lind@digia.com>
  35. 26 Sep, 2013 1 commit
  36. 08 Jul, 2013 1 commit
    • Tor Arne Vestbø's avatar
      Restore smooth-scaled drawing of 0.5x-2.0x scaled glyphs in the GL engine · df1e835f
      Tor Arne Vestbø authored
      Commit b5922c89 (Add support for retina glyph-based text drawing
      in the GL engine), and commit 155a2062 (Use QPaintEngineEx to decide
      if font is too big for using the glyph cache) together changed the
      behavior of drawing scaled cached glyphs in the GL engine, producing
      blocky text drawing when using the FreeType font engine.
      Whereas before we would cache all glyphs without any transform, and
      let the paint engine take care of the transform, commit b5922c added
      support for a scaled GL glyph cache, resulting in a 2x cache, drawn
      at 1x for example. The problem was that the FreeType engine claimed
      to support producing glyphs at 2x, but did that using the QFontEngine
      baseclass implementations, which use a simple fast-transform to scale
      up the glyphs. The result was a 2x cache with horrible looking glyphs.
      The first step in fixing this issue was to have the FreeType engine
      claim to only support translations. This would then make the paint
      engine choose path-based drawing for all scaled text, which is slow.
      To restore the optimization that we would draw 0.5x-2.0x scaled text
      using a smooth-scale in the GL engine (which was removed in 155a2062
      we then needed to extend shouldDrawCachedGlyphs() and add a special
      condition for this, coupled with a bit of logic in drawCachedGlyphs()
      that ensures we don't propagate the painter scale to the glyph cache
      if the engine is not able to produce scaled glyphs for it. This
      means we get the old behavior of the GL engine doing a smooth scale
      of the 1x glyph in the cache.
      Finally, since the raster engine also checks if the font engine
      supports the current transform, but for FreeType then ends up in
      a separate code path when actually drawing the glyphs (as the
      FreeType font engine supports internal glyph caching), we need
      to add a corresponding check for hasInternalCaching() in the
      shouldDrawCachedGlyphs() function, now that the FreeType engine
      only reports that it supports translations.
      Change-Id: Id03de896dec5f29535b281fb235332ef018045d8
      Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
  37. 03 Jul, 2013 1 commit
  38. 07 May, 2013 1 commit
    • Tor Arne Vestbø's avatar
      Don't use GL_REPEAT for image-brush drawing on OpenGL ES2 · 8dfeb1c3
      Tor Arne Vestbø authored
      OpenGL ES2 doesn't support NPOT textures in combination with GL_REPEAT,
      so for OpenGL ES2 we use a custom program that emulates repeat by taking
      the fractional part of the texture coordinates.
      This is not enough though, as merely setting GL_TEXTURE_WRAP_x to GL_REPEAT
      with a NPOT texture is an error in some implementations, so we have to
      guard the call to updateTextureFilter() in updateBrushTexture() with
      a check for OpenGL ES2 and use GL_CLAMP_TO_EDGE instead.
      This fixes missing/black backgrounds in the diagramscene example on iOS.
      Change-Id: I5020090b5f17faeb06dcab9dc0292459e021af30
      Reviewed-by: default avatarRichard Moe Gustavsen <richard.gustavsen@digia.com>
      Reviewed-by: default avatarSamuel Rødal <samuel.rodal@digia.com>
  39. 13 Feb, 2013 1 commit