| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you link cross-compiled applications on Linux, the linker needs to
be able to find not just the libraries the application links against
(like libQtGui.so), but the libraries' dependencies. E.g.
examples/widgets/wiggly links against QtGui. QtGui links against
libEGL.so. Therefore, when you link wiggly, the linker has to be able to
find libEGL.so, even though wiggly doesn't use EGL directly.
To facilitate this, -Wl,rpath-link=/path/to/egl needs to be added to
QMAKE_PRL_LIBS in libQtGui.prl and -Wl,rpath-link=/path/to/gl needs to
be added to QMAKE_PRL_LIBS in libQtOpenGL.prl. This only needs to be
done when the EGL/GL libs are not in the default search directories. As
the paths will also change depending on the mkspec, two new variables
have been added: QMAKE_LFLAGS_EGL & QMAKE_LFLAGS_OPENGL. These can be
set in the mkspec and will be added to the relevent prls. E.g.
QMAKE_LFLAGS_EGL += -Wl,-rpath-link=$${QMAKE_LIBDIR_EGL}
QMAKE_LFLAGS_OPENGL += -Wl,-rpath-link=$${QMAKE_LIBDIR_OPENGL}
Reviewed-by: Marius Storm-Olsen
|
| |
|
|
|
|
|
|
|
|
| |
Previously, QtOpenGL assumed that by linking against QtGui, it would
automatically also be linked against EGL. However, this is no longer the
case after 83940f25dba51a9942ab55ed8475fc7fc8a8da84 which makes sure
only QtGui links against EGL and not other libs/apps linking against
QtGui.
Reviewed-by: Rhys Weatherley
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also refactors QGL2PaintEngineEx::ensureActive() and the
logic which handles multiple paint engines rendering to the same
QGLContext. In a nut-shell:
* QGLPaintDevice::beginPaint() stores the currently bound FBO
* QGLPaintDevice::ensureActiveTarget() makes sure that GL rendering will
end up in the paint device (I.e. the right context is current and the
right FBO is bound). If a different context or FBO was bound, it is
_not_ remembered.
* QGLPaintDevice::endPaint() restores whatever FBO was bound when
beginPaint() was called.
This logic allows interleaved painter rendering to multiple FBOs and
contexts to work as expected. It also allows a stacked begin/end to work
properly when it's mixed with native GL rendering (as far as current
render target is concerened. GL state clobbering is obviously a
different topic).
QGLPaintDevice::context() also had to be made virtual as there's no good
place to call setContext. This might be possible to change in the future
though.
Finally, to make this work, QGLFramebufferObjectPrivate had to be moved
into it's own private header.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new abstract base class which inherits from
QPaintDevice called QGLPaintDevice. This base class will contain
everything the GL paint engines need to know about the surface they are
drawing onto. As such, new surfaces can be targeted by the GL paint
engines without having to modify QtOpenGL. This is very useful for
plugins, specifically QGraphicsSystem plugins.
To unify things a little, the GL paint engines will use the same
QGLPaintDevice API to render into existing target surfaces (QGLWidget,
QGLPixelBuffer & QGLFrameBufferObject). Ideally we'd make QGLPaintDevice
a common ancestor for these surfaces, but obviously that wil break B/C.
This patch only implements QGLWidget using the new interface. Rendering
to other surfaces will be fixed in following patches.
|
| |
|
|
|
|
|
| |
The custom shader code in the OpenGL2 paint engine needs time to
mature before we make this official public API.
Reviewed-by: trustme
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On the Mac, it means "-framework ApplicationServices -framework Carbon
-framework AppKit" are no longer part of the default LIBS in Qt
applications. This required a lot of fixes where we used Mac-specific
code in Qt.
On X11, it was very straightforward, because we apparently use very
little of X11 outside QtGui.
I haven't changed the Windows-specific LIBS paths, because I don't
know how Windows behaves. Windows has DLLs, but it links to static
"import" libraries. So is it static linking or dynamic linking?
Reviewed-By: Marius Storm-Olsen
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/graphicsview.pri
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem.h
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene.cpp
tests/auto/auto.pro
|
| | |
| |
| |
| | |
Reviewed-By: Trustme
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
This change also moves the EGL support classes from QtOpenGL to QtGui
so they can be shared between OpenGL and OpenVG.
|
| | |
|
| |
|
|
|
|
|
| |
Compile both GL and GL2 paint engine on desktop, and choose between them
at run-time based on GL version flags.
Reviewed-by: Tom
|
| |
|
|
|
|
|
|
|
| |
Clean up the extension naming and make things build on OpenGL ES 2.0
again. All the extensions which made it into OpenGL 2.0 spec have have
the EXT postfix removed. This also eliminates defines on ES 2.0 as the
code now refers to the in-spec names.
Reviewed-by: sroedal
|
| |
|
|
|
| |
Enable GL graphics system on ES 2.0 builds - it wont work, but now
QGLDrawable is being used it's just easier to build the graphics system.
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
src/opengl/gl2paintengineex/qpaintengineex_opengl2.cpp
src/opengl/opengl.pro
|
| | |\
| | |
| | |
| | |
| | | |
Conflicts:
src/opengl/opengl.pro
|
| | | |
| | |
| | |
| | |
| | |
| | | |
glpixmapfilter should not be compiled for OpenGL ES 2.0 on nay platform
Reviewed-by: Tom Cooksey
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |/ |
|
| |
|
