mirror of
https://github.com/qgis/QGIS.git
synced 2025-02-26 00:02:08 -05:00
3b56b79f6d
In some cases canceling render jobs can take a long time. Eg when using database layers over a sloooooow connection, canceling a job can be blocked by minutes while waiting for the first batch of feature fetching to finish. (Since eg postgres features are fetched in batches of 2000 with no opportunity to abort mid-way through this). This meant that while the first render allows the GUI to remain responsive, any subsequent render operations which occured before the first render completes locks up the whole ui until the first render can finish cancellation. With this change, the render cancelation happens with blocking. It means that you can pan and zoom around a map over of slow connection without any ui locks.
57 lines
2.3 KiB
Plaintext
57 lines
2.3 KiB
Plaintext
|
|
/** Job implementation that renders everything sequentially using a custom painter.
|
|
*
|
|
* Also supports synchronous rendering in main thread for cases when rendering in background
|
|
* is not an option because of some technical limitations (e.g. printing to printer on some
|
|
* platforms).
|
|
*
|
|
* @note added in 2.4
|
|
*/
|
|
class QgsMapRendererCustomPainterJob : QgsMapRendererJob
|
|
{
|
|
%TypeHeaderCode
|
|
#include <qgsmaprenderercustompainterjob.h>
|
|
%End
|
|
|
|
public:
|
|
QgsMapRendererCustomPainterJob( const QgsMapSettings& settings, QPainter* painter );
|
|
~QgsMapRendererCustomPainterJob();
|
|
|
|
virtual void start();
|
|
virtual void cancel();
|
|
virtual void cancelWithoutBlocking();
|
|
virtual void waitForFinished();
|
|
virtual bool isActive() const;
|
|
virtual bool usedCachedLabels() const;
|
|
virtual QgsLabelingResults* takeLabelingResults() /Transfer/;
|
|
|
|
//! @note not available in python bindings
|
|
// const LayerRenderJobs& jobs() const { return mLayerJobs; }
|
|
|
|
/**
|
|
* Wait for the job to be finished - and keep the thread's event loop running while waiting.
|
|
*
|
|
* With a call to waitForFinished(), the waiting is done with a synchronization primitive
|
|
* and does not involve processing of messages. That may cause issues to code which requires
|
|
* some events to be handled in the main thread. Some plugins hooking into the rendering
|
|
* pipeline may require this in order to work properly - for example, OpenLayers plugin
|
|
* which uses a QWebPage in the main thread.
|
|
*
|
|
* Ideally the "wait for finished" method should not be used at all. The code triggering
|
|
* rendering should not need to actively wait for rendering to finish.
|
|
*/
|
|
void waitForFinishedWithEventLoop( QEventLoop::ProcessEventsFlags flags = QEventLoop::AllEvents );
|
|
|
|
/**
|
|
* Render the map synchronously in this thread. The function does not return until the map
|
|
* is completely rendered.
|
|
*
|
|
* This is an alternative to ordinary API (using start() + waiting for finished() signal).
|
|
* Users are discouraged to use this method unless they have a strong reason for doing it.
|
|
* The synchronous rendering blocks the main thread, making the application unresponsive.
|
|
* Also, it is not possible to cancel rendering while it is in progress.
|
|
*/
|
|
void renderSynchronously();
|
|
|
|
};
|