[Qgis-developer] Multi-threading rendering merged to master

[Larry Shaffer]

Hi Martin and Mathieu,

On Wed, Feb 26, 2014 at 6:41 AM, Mathieu Pellerin <nirvn.asia at gmail.com>wrote:

> Happy to report that following Martin's last commit (
> https://github.com/qgis/QGIS/commit/daf1e0b6881cdb77df6f6a9dc988ad92e0f9019d),
> I cannot see any issues with vector/raster layer rendering, as well as
> labelling. All renders like 2.2, except the user experience is 10 times
> better :)
>
> Larry, I'm pretty sure your labeling tests will mostly turn green now.
>

Yes and no. :-)

The server and composer tests, and comparisons with canvas output ,seem to
pass OK now, but not so for the canvas [0]. Now, I don't know if it is the
unit test setup that needs updated to work with new QgsMapSettings or
something in PAL, so I have to do some investigation first.

On Wed, Feb 26, 2014 at 3:59 PM, Martin Dobias <wonder.sk at gmail.com> wrote:

> Hi Larry
>
> On Tue, Feb 25, 2014 at 5:55 AM, Larry Shaffer <larrys at dakotacarto.com>
> wrote:
> > Hi Martin,
> >
> > This is just awesome work!
> >
> > Unfortunately, all but the simplest labeling tests (default labels of mm
> > unit) fail, especially any that utilize labels in map units. In your
> > forthcoming detailed description of changes you mentioned, could you add
> > some info on what may have changed with regards to output resolution?
>
> I am sorry about that, but I am sure we can sort it out in the next
> few days. Mathieu has done a great job testing post-MTR rendering and
> reporting regressions, just today he has added #9661 and #9662 - maybe
> these are the issues causing the tests fail.
>
> The main change is that doing size/width calculations should get
> simpler now, because the "scale factor" and "raster scale factor" are
> now always equal to one (so we do not need to use them anymore) and
> there is just one true DPI (instead of two DPIs - painter DPI and
> scene DPI). I know that labeling had to do some voodoo to get the
> rendering right, I remember updating that code, but maybe I missed
> some pieces....
>

Hmm. I didn't figure everything would go smoothly. :-)

Stripping out all the vector and raster scale adjustments from labeling
will be great.

But, the code removed in [1] is exactly the only thing that I thought I
would need to leave in. It is used to find the difference in dpi from a
native, local painter, versus the current render context. That is in turn
used by the drop shadow and other functions to make sure their output
matches the current painter's scale, since I leverage a local painter and
QPicture to generate the silhouette of the label component, which is the
basis for the drop shadow.

Do you know of a way to effectively copy the main painter to a local one?
Does the new renderer setup offer a means to duplicate the painter?

Might have to switch the whole operation over to using Qt 4.6+
QGraphicsEffect drop shadows for QGraphicItems (tried that first, but had
odd results). Could work better now with the new renderer setup.

I won't be able to verify the issues that removing the noted code produces
until I am done adding many more unit tests.

I'm looking at adding two more unit test rendercheckers: composer export to
PDF and SVG, then rasterize those back to PNG for comparing against
composer and canvas outputs. This means for every individual labeling unit
test, the following suite will be auto-generated:

Self-comparisons
* canvas (done)
* server (done)
* composer image (done)
* composer PDF
* composer SVG

Cross-check comparisons
* server vs. canvas (done)
* composer image vs. canvas (done, but has double anti-aliasing issue)
* composer PDF vs. composer image [and canvas?]
* composer SVG vs. composer image [and canvas?]

All outputs that support different resolutions should also have suites
associated with a likely range that may expose issues, e.g. 72, 150, 300
dpi. Needless to say, many of these tests will have varying allowable
tolerances, given font differences across platforms.

The focus, at least for me, is to have the unit tests point towards glaring
issues with QGIS code, not precisely solve cross-platform font issues nor
have all output match cross-platform. Ideally, they should help ensure
user's output is generally WYSIWYG in day-to-day usage.

For rendering PDF back to PNG for cross-checking, I am looking at muPDF and
poppler libs [2], both recommended by the Qt project [3]. There is also
pdf2image [4], but that depends upon ghostscript.

[0] http://drive.dakotacarto.com/qgis/PALTestReport_2014-02-26_10-13-21.pdf
[1] https://github.com/qgis/QGIS/commit/daf1e0b

[2] http://people.freedesktop.org/~aacid/docs/qt4/
[3] http://qt-project.org/wiki/Handling_PDF#a6e8f9aed2ac6481dc25a18a33342d03
[4] http://code.google.com/p/pdf2image/

Regards,

Larry



> Regards
>> Martin
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140226/da4874ac/attachment-0001.html>