<div dir="ltr">Hi Martin and Mathieu,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 6:41 AM, Mathieu Pellerin <span dir="ltr"><<a href="mailto:nirvn.asia@gmail.com" target="_blank">nirvn.asia@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Happy to report that following Martin's last commit (<a href="https://github.com/qgis/QGIS/commit/daf1e0b6881cdb77df6f6a9dc988ad92e0f9019d" target="_blank">https://github.com/qgis/QGIS/commit/daf1e0b6881cdb77df6f6a9dc988ad92e0f9019d</a>), 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 :)<br>

<br></div>Larry, I'm pretty sure your labeling tests will mostly turn green now.<br></div></div></blockquote><div><br></div><div class="gmail_extra">Yes and no. :-)<br><br>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.<br>
<br><div class="gmail_quote">On Wed, Feb 26, 2014 at 3:59 PM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Larry<br>
<div><br>
On Tue, Feb 25, 2014 at 5:55 AM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>> wrote:<br>
> Hi Martin,<br>
><br>
> This is just awesome work!<br>
><br>
> Unfortunately, all but the simplest labeling tests (default labels of mm<br>
> unit) fail, especially any that utilize labels in map units. In your<br>
> forthcoming detailed description of changes you mentioned, could you add<br>
> some info on what may have changed with regards to output resolution?<br>
<br>
</div>I am sorry about that, but I am sure we can sort it out in the next<br>
few days. Mathieu has done a great job testing post-MTR rendering and<br>
reporting regressions, just today he has added #9661 and #9662 - maybe<br>
these are the issues causing the tests fail.<br>
<br>
The main change is that doing size/width calculations should get<br>
simpler now, because the "scale factor" and "raster scale factor" are<br>
now always equal to one (so we do not need to use them anymore) and<br>
there is just one true DPI (instead of two DPIs - painter DPI and<br>
scene DPI). I know that labeling had to do some voodoo to get the<br>
rendering right, I remember updating that code, but maybe I missed<br>
some pieces....<br><div><div></div></div></blockquote></div></div><div><br></div><div>Hmm. I didn't figure everything would go smoothly. :-)<br><br>Stripping out all the vector and raster scale adjustments from labeling will be great.<br>
<br>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.<br>
<br></div><div>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?<br><br></div><div>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.<br>
</div><div><br>I won't be able to verify the issues that removing the noted code produces until I am done adding many more unit tests.<br></div><div><br></div><div>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:<br>
<br></div><div>Self-comparisons<br></div><div>* canvas (done)<br>* server (done)</div><div>* composer image (done)</div><div>* composer PDF<br></div><div>* composer SVG<br><br>Cross-check comparisons<br>* server vs. canvas (done)<br>
* composer image vs. canvas (done, but has double anti-aliasing issue)<br>* composer PDF vs. composer image [and canvas?]<br>* composer SVG vs. composer image [and canvas?]<br><br></div><div>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.<br>
<br>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.<br>
</div><div><br></div><div>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.<br>
</div><div><br>[0] <a href="http://drive.dakotacarto.com/qgis/PALTestReport_2014-02-26_10-13-21.pdf">http://drive.dakotacarto.com/qgis/PALTestReport_2014-02-26_10-13-21.pdf</a><br>[1] <a href="https://github.com/qgis/QGIS/commit/daf1e0b">https://github.com/qgis/QGIS/commit/daf1e0b</a><br>
<br>[2] <a href="http://people.freedesktop.org/~aacid/docs/qt4/">http://people.freedesktop.org/~aacid/docs/qt4/</a><br>[3] <a href="http://qt-project.org/wiki/Handling_PDF#a6e8f9aed2ac6481dc25a18a33342d03">http://qt-project.org/wiki/Handling_PDF#a6e8f9aed2ac6481dc25a18a33342d03</a><br>
[4] <a href="http://code.google.com/p/pdf2image/">http://code.google.com/p/pdf2image/</a><br><br></div><div>Regards,<br><br></div><div>Larry<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
Regards<br>
Martin<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div>