D8379: PDF: Support the new poppler renderToImage with update callback
Milian Wolff
noreply at phabricator.kde.org
Wed Nov 1 10:26:57 UTC 2017
mwolff added inline comments.
INLINE COMMENTS
> generator.cpp:407
> +{
> + request->page()->setPixmap( request->observer(), new QPixmap( QPixmap::fromImage( image ) ), request->normalizedRect() );
> +
is `setPixmap` old API? Why create a QPixmap on the heap? That should not be done, pass values instead.
> generator.h:581
> + * This method can be called to trigger a partial pixmap update for the given request
> + * Make sure you call it in a way it's executed in the main thread.
> + * @since 1.3
aka: "Must be called from the main thread."
> generator_pdf.cpp:919
> +
> + if (payload->timer.isActive() && payload->timer.remainingTime() == 0) {
> + payload->timer.stop();
why is the timer active when there is no remaining time? when does this happen? can you add a comment please?
> generator_pdf.cpp:929
> + auto payload = static_cast<PartialUpdatePayload *>(payloadA);
> + QMetaObject::invokeMethod(payload->generator, "signalPartialPixmapRequest", Qt::QueuedConnection, Q_ARG(Okular::PixmapRequest*, payload->request), Q_ARG(QImage, image));
> +}
sending raw pointers over a queued connection sounds scary - who owns the pixmap request? will it really outlive everything? could you instead use a shared pointer or similar value type to ensure it really never gets destroyed in the middle?
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D8379
To: aacid, #okular, mlaurent
Cc: mwolff, rkflx, ngraham, michaelweghorn, mlaurent, #okular, aacid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20171101/0612b688/attachment-0001.html>
More information about the Okular-devel
mailing list