[QGIS-Developer] qt and antialiasing - line pattern fills

[Tim Sutton]

Hi

> On 22 Jul 2020, at 08:48, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> 
> On Wed, 22 Jul 2020 at 17:39, Andreas Neumann <a.neumann at carto.net> wrote:
>> 
>> Hi Nyall,
>> 
>> Thanks for your reply.
>> 
>> Thanks for explaining the issue about the enforced rasterization of the line pattern fills. Any rough estimate how much the speed penalty would be when one would implement the line pattern fill purely as vector?
> 
> Hard to say upfront -- it's going to depend on the size (pixels) of
> the features, and the number of lines in the fill pattern. Gut feeling
> is that it's unlikely to be noticeable for individual users, but
> costly enough to be an issue for server. Somewhere in the middle
> there!
> 
>> Also - would it be possible to "enforce" vector only rendering of line and point pattern fills - not only for export, but also for server or canvas rendering? As an example, when generating raster tiles, it would be nice to get a higher quality (even on server output) at the expense of speed. When a Mapproxy is harvesting tiles from a QGIS server, it would be nice if there could be a parameter in the GetMap request that enforces higher quality vector rendering at the expense of a lower performance.
> 
> Hm -- maybe we should add a project level setting for "rendering
> quality". There's actually quite a few more shortcuts we could
> potentially take if someone just cares about fast rendering vs high
> quality rendering (e.g. rendering shapeburst fills at a lower
> resolution). So potentially we could add a setting "rendering quality"
> with options like "Prioritise speed over
> quality"/"Balanced"/"Prioritize quality over speed". (I think layout
> exports should ALWAYS use the highest quality render though, so they'd
> ignore this setting)


I’m imagining a checkbox in the status bar here next to the enable / disable render one that toggles ‘draft’ mode versus ‘awesome mode’….I love that QGIS has advanced so far that we are even having this discussion :-)





Regards

Timi

> 
> Nyall
> 
> 
>> 
>> Thanks,
>> 
>> Andreas
>> 
>> On 2020-07-22 08:32, Nyall Dawson wrote:
>> 
>> On Fri, 17 Jul 2020 at 19:34, Andreas Neumann <a.neumann at carto.net> wrote:
>> 
>> 
>> Hi,
>> 
>> In our efforts to improve cartographic quality, I'd also like to discuss, if we could somehow improve the quality of the line-pattern fills, and/or the antialiasing quality of the qt renderer. A very small change in angle can change the quality of a line-pattern fill in QGIS pretty or very ugly.
>> 
>> Also: even if all buildings in the following rendering have the same distance between lines, some look much "denser" than others. Have a look at the attached file where I labeled some line fills as ugly and pretty.
>> 
>> Is there something that QGIS could do to improve the "prettyness" of line pattern fills, or would this have to change in the qt library?
>> 
>> Thanks if you have any thoughts on this topic,
>> 
>> 
>> Sorry for the delayed reply!
>> 
>> This is a long-standing issue in QGIS' polygon fill support. See
>> https://github.com/qgis/QGIS/issues/16100 (filed 2013). Basically, the
>> line pattern symbol type uses a trick to speed up the rendering of
>> features by first making a small tiled raster image of the line
>> pattern, and then painting the polygons using this raster brush. It's
>> nice and fast, and works well for canvas/server renders, but is far
>> from ideal for high quality exports. It's also an issue if you try to
>> use data defined settings on the line sub symbol -- because the
>> pattern is generated using the tiled image, you won't see the expected
>> results if you try to make the appearance of individual lines in the
>> pattern vary.
>> 
>> For reference, up until 3.14 the point pattern fill had the same
>> limitation. For 3.14 point pattern fills were improved to now export
>> the fill as vector markers (the same raster brush approach is still
>> used for canvas renders, where speed is more important vs quality).
>> 
>> What we need to do is implement a similar fix as was done for the
>> point pattern fill, and render each individual line in a line pattern
>> fill as a proper vector line (during layout exports, or when we detect
>> that the line subsymbol has data defined properties set).  Hopefully
>> something we can do for 3.16...
>> 
>> Nyall
>> 
>> 
>> 
>> 
>> Andreas
>> 
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> 
>> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—












Tim Sutton

Co-founder: Kartoza
Honorary PSC Member and Ex-Project chair: QGIS.org <http://qgis.org/>

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link <https://calendly.com/timlinux/30min> to make finding time easy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200722/b2148cf6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200722/b2148cf6/attachment-0001.jpg>