For release, maybe disble it, and work on a solution for 1.6? A note about the raster format - I wonder if it only affects rasters without overviews. For the vrts in Greg's test, though the files referenced in the vrts are JP2s, does a vrt inherit the overviews? I did a test with a single 1 GiB JP2 and it generates the legend icon nearly instantaneously. A 1.3 GiB tiff without overviews takes a long time, yet the same with overviews is fast. A 200MiB tiff without overviews has a noticable delay, but it's not horrible.
Though, Greg's test vrts are quite small, just 14MiB across 4 vrts. Maybe there's something else with a vrt that slows down the legend generation? Zooming and panning are not affected. On Jul 6, 2010, at 4:21 AM, Marco Hugentobler wrote: >> (a raster scaled down to 16x16 pixels usually >> doesn't provide a good overview) > > I made a little self-test here and it was quite easy to distinguish different > topographic map sheets by their legend icons (even if they have exactly the > same color schema). > > Regards, > Marco > > Am Dienstag, 6. Juli 2010, um 10.26:10 schrieb Martin Dobias: >> Hi >> >> On Tue, Jul 6, 2010 at 8:35 AM, Marco Hugentobler >> >> <[email protected]> wrote: >>> Hi William >>> >>> Ah, good to know it is the icon generation that makes loading projects >>> with many raster layers slow. >>> >>> Making a user option to disable layer icons sounds good. However, this >>> would involve a string change (option dialog). String freeze for 1.5 is >>> already over for a while now. So (unless there is a better solution for >>> the problem without string change) something for 1.6... >> >> in my opinion, we could actually remove this feature. I don't find it >> particularly useful (a raster scaled down to 16x16 pixels usually >> doesn't provide a good overview), it adds additional overhead when the >> raster layer is loaded and further complicates the complex raster >> code. Another argument could be that vector layer also don't have an >> icon containing the preview. >> >> I'm just afraid of creating too many configurable options that barely >> anyone will understand their purpose. >> >> Regards >> Martin > > > -- > Dr. Marco Hugentobler > Sourcepole - Linux & Open Source Solutions > Webereistrasse 66, 8134 Adliswil, Switzerland > [email protected] http://www.sourcepole.ch > Technical Advisor QGIS Project Steering Committee > _______________________________________________ > Qgis-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-user ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
