| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| |
| |
| |
| |
| | |
Task-number: 254407
Reviewed-by: Gunnar
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
basically reordering members initialization in constructors or fixing
singed/unsigned checks.
Reviewed-by: Trustme
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The bugs were caused by not clipping to the near plane (w = 0) when
mapping primitives with perspective tranfsorms.
Task-id: 258961
Reviewed-by: Gunnar
|
|/ /
| |
| |
| | |
Reviewed-by: Samuel
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qsharedpointer.cpp
src/corelib/tools/qsharedpointer_impl.h
src/gui/dialogs/qcolordialog.cpp
src/gui/painting/qwindowsurface_raster.cpp
src/network/access/qnetworkaccessmanager.cpp
tests/auto/qsharedpointer/externaltests.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In qt_scale_image_16bit() and qt_scale_image_32bit(), when a sample
point was located on the border between two pixels in the source image,
the sample point was rounded up instead of down. If a sample point was
exactly on the bottom or right edge of the source image, the function
would therefore sample a pixel outside the image. Because of how the
target rectangle is rounded, a sample point will never be exactly on
the top or left edge of the source image, so we will not get a similar
problem there.
I extended the lance test pixmap_scaling.qps.
Task-number: 258533
Reviewed-by: Samuel
|
| |
| |
| |
| | |
Reviewed-by: Samuel
|
| |
| |
| |
| |
| |
| |
| |
| | |
When using drawLines() then the dash offset was remembering where it
was on the previous line. This is not what the behaviour should be
as it should be starting with the same offset for each line.
Reviewed-by: Samuel
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Copy the first line from the texture to the destination
and from then on reference that copy reducing cache misses. Also
progressively copy larger sizes, reducing the amount of time spend
figuring out what to copy.
Merge-request: 371
Reviewed-by: Samuel Rødal <sroedal@trolltech.com>
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Squashed commit of the following:
commit fcf7e8cab339d0cf9f3f2a9756d7754c54c4d934
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Thu Jul 30 13:15:13 2009 +0200
note in the changes file...
commit 2c9c3880215988e6609c290a8e738b228736e601
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Thu Jul 30 12:51:42 2009 +0200
Don't leak native window HRGN handles
commit 6bb30d2075dd1d71a8a600d25f413a38af7f2f2c
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Thu Jul 30 11:09:22 2009 +0200
Moved qregion_wince.cpp -> qregion_win.cpp, platforms are identical now
commit 173fcc5baec73a198167985c6f777987e6015a71
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Thu Jul 30 09:42:06 2009 +0200
win32 calls on QRegion.handle() is no longer supported, use from HRGN
commit d7ddcce4ba29b70ed81f85274208b388a2bb9d4d
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Thu Jul 30 09:41:37 2009 +0200
Added convenience function to convert from HRGN to QRegion
commit 2fc53ac3d59a9c42bb4154fff7557610092b7946
Author: Gunnar Sletta <gunnar@trolltech.com>
Date: Wed Jul 29 09:28:10 2009 +0200
Kill qregion_win.cpp and use the unix code instead
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also add 2 new flags and a new member to store any GL bound pixmap
surface (GLXPixmap or EGLPixmapSurface).
Reviewed-By: Samuel
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
HIViewSetNeedsDisplayInRegion fails on large regions with large
coordinates, fall back on updating the entire region in this case.
The task mentions coordinates outside the range of signed short, but
the provided example demonstrates failures in the 10-20K range as well.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes Qt work on VxWorks 6.6+ in native (kernel) mode.
* compiles with the WindRiver GNU toolchain (Linux only)
* works with QWS (tested with the VNC driver only)
* tested on PPC hardware and the x86 VxWorks simulator
* no q3support, no phonon, no webkit
* no QSharedMemory, no QSystemSemaphore, no QProcess
* only one QApplication instance (flat address space)
* filesystem support depends heavily on the quality of the native driver
* QLibrary is just a dummy to make plugins work at all
* qmake transparently creates VxWorks munching rules for static ctors
* made auto-test cope with missing OS features
A special note regarding the Q_FOREACH patch for dcc:
when calling foreach(a,c) with c being a function returning a container,
the compiler would generate 5 references to some labels (.LXXXX), which
are not there (so the linker complains in the end).
Seems like dcc doesn't really like the 'true ? 0 : <function call to get type>'
statement
Reviewed-By: Harald Fernengel
|
|\ \ \ |
|
| | | | |
|
| |/ /
| | |
| | |
| | | |
This closes task 235801.
|
| | |
| | |
| | |
| | | |
Reviewed-by: Samuel
|
| | |
| | |
| | |
| | | |
Reviewed-by: Samuel
|
| | |
| | |
| | |
| | | |
Reviewed-by: Samuel
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| | |
As pointed out on IRC, setTransform is used most frequently in code and in
an ideal world would be the only such function.
|
| |
| |
| |
| | |
Reviewed-by: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QTransform and respective APIs should be used. Still some changes required
- Some references to QMatrix left in documentation
- Qt code uses QMatrix APIs (ie translationX)
Reviewed-by: Samuel
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Panther was the last reason for having this around. We don't touch this
code anywhere else in Qt. As a result it's orphaned and can be safely
removed. It truly is the end of an era, but it's definitely worth
celebrating. Quartz4Life!
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
The check in QPainter::checkEmulation was just plain wrong.
Reviewed-By: Eskil
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/webkit/VERSION
src/3rdparty/webkit/WebCore/ChangeLog
src/3rdparty/webkit/WebCore/bridge/qt/qt_instance.cpp
src/3rdparty/webkit/WebCore/bridge/qt/qt_instance.h
src/3rdparty/webkit/WebCore/page/DragController.cpp
src/3rdparty/webkit/WebKit/qt/Api/qwebframe.cpp
src/3rdparty/webkit/WebKit/qt/ChangeLog
src/3rdparty/webkit/WebKit/qt/tests/qwebpage/tst_qwebpage.cpp
src/gui/painting/qpaintengineex_p.h
tools/linguist/lupdate/main.cpp
|
| |
| |
| |
| |
| |
| |
| | |
Polygonal vector paths may have types==null, in which case this
would have crashed.
Reviewed-by: Eskil
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason being that there was an assumption that any non-curved path
was a continous polyline. For paths with multiple subpaths in it
we need to split this up into multiple strokePolygonCosmetic calls.
Task-number: 257621
Reviewed-by: Kim Motoyoshi Kalland
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We normally pad the clip rect with the size of the pen and miterlimit
to avoid this, but this didn't handle the case where there was a long
diagonal dash. We also need to multiply the padding with the longest
dash.
Reviewed-By: Tom Cooksey
|
| |
| |
| |
| |
| |
| |
| | |
This is a huge impact on performance whenever this path is
taken.
Reviewed-By: Tom Cooksey
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm not all to happy with this fix, but its the best that one can
acheive given the current design. The problem is that QPdfBaseEngine
sets a number of states as part of updateState(), but only when we are
playing back through the alpha engine. These states are used in some
draw functions, also when we are recording in the alpha engine. This
leads to the states and their checks being out of sync. So to follow
the existing pattern in the code we need to not touch d-> vars prior
to a check to usesAlphaEngine.
Reviewed-By: Eskil
|
| |
| |
| |
| | |
Reviewed-by: Lincoln Ramsay
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/webkit/VERSION
src/3rdparty/webkit/WebCore/ChangeLog
src/3rdparty/webkit/WebCore/generated/JSDOMWindow.cpp
src/3rdparty/webkit/WebCore/page/DOMWindow.idl
src/corelib/io/qdiriterator.cpp
src/plugins/gfxdrivers/directfb/qdirectfbpaintengine.cpp
src/plugins/gfxdrivers/directfb/qdirectfbpixmap.h
tests/auto/qxmlquery/tst_qxmlquery.cpp
tools/linguist/lconvert/main.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First, don't call QWSWindowSurface::winId() in the destructor, as it
will actually request a new id if there isn't already one around - which
is a bit silly and highlighted the "real" bug.
Second, make sure QWSDisplay::Data::takeId() asks for 1 new id before
waiting for more ids to arrive. This is because waitForCreation() calls
QWSServer::processEventQueue(). If the events in the queue cause
takeId() to be called, QWSDisplay::Data::takeId() gets called
recursively. Even though there will be a create 15 ids command in the
queue, that will only allow 15 QWSDisplay::Data::takeId() calls to
return. The 16th call to QWSDisplay::Data::takeId() on the stack will
not be able to return because all the IDs have been taken and (because
it has been called recursively) no new create id commands have been
generated. So the 16th call to takeId() spins in waitForCreate().
Reviewed-by: Paul
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
did a small refactor and used QStyleHelper::uniqueName in plastique and
windows styles
|
| |
| |
| |
| |
| | |
we should include qt_windows.h and not windows.h because we have to
define WINVER to 0x500.
|
| |
| |
| |
| | |
Reviewed-By: ossi
|