Quem trabalha com bibliotecas extensas de símbolos SVG no QGIS provavelmente já percebeu um comportamento incômodo: o seletor de SVG pode se tornar lento à medida que a quantidade de arquivos aumenta.
A explicação mais comum para esse problema costuma ser simples: o QGIS estaria demorando para percorrer os diretórios e localizar os arquivos SVG disponíveis. À primeira vista, essa hipótese parece razoável. Afinal, centenas ou milhares de arquivos precisam ser encontrados e listados.
Mas será que esse é realmente o gargalo?
Com essa pergunta em mente, iniciei uma investigação diretamente no código-fonte do QGIS para entender onde o tempo de processamento está sendo gasto.
Primeira hipótese: a busca dos arquivos SVG
O primeiro componente analisado foi a classe responsável por localizar os arquivos SVG disponíveis no sistema:
QgsSvgSelectorLoader
Ao examinar sua implementação, a expectativa inicial era encontrar uma rotina de varredura executada diretamente na interface gráfica, o que explicaria travamentos durante a navegação.
Entretanto, a análise mostrou um cenário diferente.
O carregamento é executado em uma thread separada da interface principal. Além disso, os resultados não são enviados todos de uma vez. O carregador utiliza um mecanismo de atualização progressiva, emitindo lotes de resultados conforme os arquivos são encontrados.
Essa arquitetura reduz significativamente o impacto da enumeração de diretórios sobre a interface gráfica.
Em outras palavras: a simples busca dos arquivos SVG dificilmente explica, sozinha, a lentidão observada pelos usuários.
Entendendo o funcionamento do carregador
A função principal analisada foi:
QgsSvgSelectorLoader::run()
Durante sua execução, ela:
- Inicializa o processo de carregamento;
- Reinicia estados internos;
- Configura um temporizador adaptativo;
- Percorre os diretórios configurados;
- Envia resultados em lotes para a interface.
O percurso dos diretórios é realizado por:
loadPath()
Essa função realiza a busca recursiva dos SVGs e inclui mecanismos para evitar loops causados por links simbólicos circulares.
Os arquivos encontrados são encaminhados para:
loadImages()
que os adiciona a uma fila interna e emite atualizações periódicas para a interface.
A conclusão dessa etapa da investigação foi clara:
A enumeração dos SVGs já possui uma arquitetura relativamente eficiente e não parece ser o principal gargalo.
Mudando o foco da investigação
Se o problema não estava na descoberta dos arquivos, então onde estava?
O próximo passo foi acompanhar o que acontecia depois que os SVGs já haviam sido localizados.
A atenção passou então para:
QgsSvgSelectorListModel::data()
Essa função é chamada repetidamente pela interface para obter informações dos itens exibidos na lista.
Foi nesse ponto que surgiram indícios mais fortes de consumo excessivo de processamento.
O custo oculto das miniaturas
Ao analisar o fluxo de execução, observou-se que a obtenção das miniaturas envolve uma cadeia relativamente complexa de operações.
Entre elas:
createPreview()
QgsSvgCache::containsParams()
svgAsImage()
QSvgRenderer
QDomDocument
Embora cada chamada individual pareça simples, o custo acumulado pode se tornar significativo quando centenas ou milhares de SVGs precisam ser exibidos simultaneamente.
Em vários casos, o mesmo arquivo SVG pode ser analisado mais de uma vez para responder perguntas diferentes durante a geração da miniatura.
Isso significa:
- múltiplas leituras;
- múltiplos parses XML;
- múltiplas renderizações;
- múltiplas consultas ao cache.
Quando a biblioteca de símbolos cresce, o impacto dessas operações torna-se perceptível para o usuário.
Uma hipótese importante
Durante a investigação surgiu uma hipótese particularmente interessante.
O problema principal pode não ser a busca dos SVGs nem a renderização em si, mas a repetição de trabalho.
Se o mesmo arquivo SVG for processado diversas vezes para gerar uma única miniatura, o custo total cresce rapidamente.
Esse comportamento sugere oportunidades claras de otimização.
Possíveis melhorias
Com base na análise realizada, algumas estratégias parecem promissoras:
1 – Geração assíncrona de miniaturas
Atualmente a interface pode acabar aguardando a criação das pré-visualizações.
Uma fila dedicada para thumbnails reduziria a sensação de travamento.
2 – Cache de parâmetros SVG
Chamadas repetidas para:
containsParams()
poderiam ser evitadas por meio de armazenamento em memória.
3 – Evitar múltiplos parses do mesmo arquivo
Um único parse poderia alimentar diversas etapas do processo de renderização.
4 – Cache mais agressivo de miniaturas
Uma vez gerada, a miniatura poderia ser reutilizada com maior frequência.
5 – Uniformização dos tamanhos dos itens
O uso de:
setUniformItemSizes(true)
pode reduzir o custo de cálculo de layout em listas muito extensas.
Conclusão
A investigação mostrou que a explicação mais intuitiva nem sempre é a correta.
Embora seja tentador atribuir a lentidão do seletor de SVG à simples busca dos arquivos em disco, a análise do código-fonte sugere que o verdadeiro gargalo está mais relacionado à geração e ao processamento das miniaturas exibidas pela interface.
A arquitetura de carregamento dos arquivos já utiliza threads e atualizações em lote. O custo mais significativo parece surgir posteriormente, durante a construção das pré-visualizações dos símbolos.
Naturalmente, uma confirmação definitiva exigiria medições detalhadas de desempenho e instrumentação do código. Ainda assim, a análise realizada indica caminhos promissores para futuras otimizações e ajuda a compreender melhor o comportamento do seletor de SVG do QGIS quando utilizado com grandes bibliotecas de símbolos.
Próximos passos
Esta investigação ainda está em andamento.
Nas próximas etapas pretendo realizar medições mais detalhadas, identificar quantitativamente os pontos de maior consumo de tempo e avaliar possíveis estratégias de otimização para reduzir a latência do seletor de SVG no QGIS.
11 de Junho de 2026 – Alan A. Alievi
Deixe uma resposta