Leaflet: Espaço entre blocos em níveis de zoom fracionários em navegadores Webkit

Nenhuma idéia. :( Embora eu só tenha visto o problema no Safari, - Chrome / Opera funcionou bem.

Alguém tem uma ideia de como isso pode ser consertado?

Tenho uma ideia, mas está ligada às palavras "radical" e "experimental":

https://github.com/IvanSanchez/Leaflet.gl

Uma das coisas que descobri é que as texturas precisam ser fixadas. ou seja, se esta linha for removida: https://github.com/IvanSanchez/Leaflet.gl/blob/master/src/core/GlUtil.js#L74 lascas ("espaços entre as peças") aparecem (conforme a textura envolve o triângulo e meio pixel do outro lado do ladrilho). Portanto, meu palpite é que o Webkit está suavizando meio pixel na borda de cada imagem.

A partir de agora, os triângulos da camada de til formam uma malha completa que é renderizada sem lascas ... mas as palavras "experimental" estarão presentes por enquanto.

@mourner Tem um efeito mais forte no Safari, mas também é visível no Chrome.

@IvanSanchez Uau, bom trabalho, mas não acho que posso usar isso (ainda).

@Eschon sim, provavelmente não percebi isso porque na tela Retina, é ainda menos visível.

Isso parece afetar o Firefox agora também em alguns casos.
Não consegui reproduzi-lo no jsFiddle, mas se você olhar naquele site
Obtenho os mesmos espaços no Firefox 39 e 41.0a2

Edit: Este parece ser um problema com iframes. Se eu abrir o mapa diretamente, ele não se reproduz.

Duvido que isso seja possível para 1.0 sem muitos hackers. Empurrando para o fundo da lista de pendências.

Também experimentamos o mesmo problema no Chrome mais recente. Desejo que você encontre uma solução possível, pois os mapas do OpenStreet não aparecem bem com essas linhas. Obrigado.

Especialmente em mapas ou imagens mais escuras (no meu caso), o problema é bastante perceptível. Eu acho que o antialiasing no navegador causa os espaços entre os tiles devido à transformação _fractional_ durante o zoom, conforme mencionado por Ivan.

Até que uma solução melhor esteja disponível, usarei esta solução alternativa (ou hack) para aumentar os tiles 1 pixel, com o efeito colateral de que eles se sobrepõem em 1 px. Além disso, os blocos serão ligeiramente aumentados e redimensionados (em 1px).

/* 
 * Workaround for 1px lines appearing in some browsers due to fractional transforms
 * and resulting anti-aliasing.
 * https://github.com/Leaflet/Leaflet/issues/3575
 */
(function(){
    var originalInitTile = L.GridLayer.prototype._initTile
    L.GridLayer.include({
        _initTile: function (tile) {
            originalInitTile.call(this, tile);

            var tileSize = this.getTileSize();

            tile.style.width = tileSize.x + 1 + 'px';
            tile.style.height = tileSize.y + 1 + 'px';
        }
    });
})()

@cmulders Obrigado pela solução alternativa!
Uma vez que temos principalmente mapas de estações de esqui, em sua maioria brancos e azuis. Ignoramos os espaços por enquanto, com sua solução alternativa parece muito melhor.

Feito um jsbin com ladrilhos escuros de cartodb, as linhas são visíveis mesmo na tela de retina:
http://jsbin.com/ratoli/5/edit?html , js, output

Bug Safari / Chrome, FF OK para mim.

Devemos fazer um relatório de bug do Chrome sem folheto para isso, para que seja corrigido em futuras versões do Chrome.

@hyperknot Acho que já existe um relatório de bug do Chrome, mas não consigo encontrá-lo agora.

Estou usando o leafletjs 1.0 beta e às vezes também vejo esse bug no (mais recente: chrome, safari, firefox) no osx El Capitan. quando edito a propriedade transform css de uma imagem em 1px, o bloco editado se alinha com o bloco próximo a ele.

// ex.
 transform: translate3d(1556px, -81px, 0px);
 // to
 transform: translate3d(1555px, -80px, 0px);

Às vezes, esse bug não aparece (aquele 1px de diferença) !! não tenho certeza do motivo :( mas estou supondo que tenha a ver com o estilo do contêiner do mapa.

Editar: diga que os blocos estão alinhados corretamente na renderização e não mostram qualquer 1px de diferença, uma lacuna será visível no evento de movimentação do mapa. O comportamento é como o flash de uma borda de 1 px ao redor do bloco.

Encontrei uma solução alternativa para o CSS que elimina o problema para mim no Safari 9.1 no OS X El Capitan:

.leaflet-tile-container img {
    box-shadow: 0 0 1px rgba(0, 0, 0, 0.05);
}

Não posso aceitar muito crédito, no entanto, tirei isso da seguinte resposta do Stackoverflow, que também indica _por que_ isso ajuda: http://stackoverflow.com/a/17822836/138103

O uso de box-shadow resolve o problema mais diretamente: estende as dimensões de repintura da caixa, forçando o WebKit a repintar os pixels extras. As implicações de desempenho conhecidas da sombra de caixa em navegadores móveis estão diretamente relacionadas ao raio de desfoque usado, portanto, uma sombra de um pixel deve ter pouco ou nenhum efeito.

Talvez isso possa ser usado como uma solução adequada, embora provavelmente seria bom se outros tentassem primeiro. No entanto, funciona para mim e não parece causar problemas em outros navegadores.

@href Talvez você pudesse fazer uma solicitação de pull com essa correção? Isso tornaria mais fácil o teste.

@href @IvanSanchez Tem certeza de que isso não afetará o desempenho de renderização? Acho que devemos definir o perfil de como a adição de uma sombra de caixa com uma opacidade alfa afeta os dispositivos móveis, por exemplo, pode ter um efeito visível no desempenho ou até mesmo possivelmente desativar a aceleração de hardware.

@IvanSanchez feito.

Tem certeza de que isso não afetará o desempenho de renderização? Acho que devemos definir o perfil de como a adição de uma sombra de caixa com uma opacidade alfa afeta os dispositivos móveis, por exemplo, pode ter um efeito visível no desempenho ou até mesmo possivelmente desabilitar a aceleração de hardware para panorâmica.

Não tenho certeza de qual é o efeito disso. Pela resposta do Stackoverflow, isso não parece ter efeito, mas é apenas confiar na opinião de outra pessoa sobre uma questão tangencialmente relacionada. Certamente seria uma ótima ideia se alguém com mais conhecimento pudesse analisar e criar um perfil de minha solução alternativa.

Tive sorte quando pesquisei no Google e queria que outras pessoas soubessem.

@hyperknot @href Com prazer realizarei alguns benchmarks em algumas semanas em meu conjunto de navegadores de teste.

@IvanSanchez @href Além disso, pode ser bom limitar este hack apenas aos navegadores afetados, não apenas aplicá-lo globalmente.

@IvanSanchez existe um fluxo de trabalho recomendado para

Além disso, pode ser bom limitar esse hack apenas aos navegadores afetados, não apenas aplicá-lo globalmente.

Pessoalmente, só o vejo no Safari, então faria sentido limitá-lo para o safári. No entanto, houve menções de pessoas vendo isso no Chrome. Alguém ainda vê esse bug em outros navegadores do webkit?

É bastante trivial adicionar uma classe CSS ao mapa apenas para navegadores selecionados, nas coisas do construtor L.Map .

@href O problema está presente no meu Chromium 49

@hyperknot Não conheço a melhor maneira de

@href Além disso, essa correção bagunça os tiles no meu Chromium 49 ... embaça a imagem inteira em vez de apenas a borda. Original, com .leaflet-container { background: black } :

Com img.leaflet-tile.leaflet-tile-loaded { box-shadow: 0 0 1px rgba(0, 0, 0, 0.05); } :

: cry_cat_face:

Isso é estranho. O problema não está presente para mim no Chromium 49 (OS X El Capitan), nem a sombra da caixa parece ter qualquer influência de qualquer maneira.

Feito um playground atualizado: http://playground-leaflet.rhcloud.com/yid/1/edit?html , saída

Enviarei bugs sem folheto para as equipes do Webkit e do Blink.

OK, fiz com sucesso um exemplo mínimo sem folheto reproduzindo o problema:
http://playground-leaflet.rhcloud.com/say/1/edit?html , saída

Relatório de bug do Chromium enviado: https://bugs.chromium.org/p/chromium/issues/detail?id=600120

Bug do Webkit enviado: https://bugs.webkit.org/show_bug.cgi?id=156130

versão sem img: http://playground-leaflet.rhcloud.com/foqi/1/edit?html , saída

Alguma atualização do relatório de bug do Chromium, de [email protected]

Ei, só quero dar a vocês uma atualização rápida. Estou trabalhando ativamente neste problema.

O problema era devido ao fato de termos rasterizado as coisas no espaço local de um elemento. Se o elemento tiver uma translação fracionária, a textura rasterizada será colada na tela com a translação fracionária usando reamostragem linear, resultando no desfoque.

A solução é rasterizar as coisas em um espaço alinhado com os pixels da tela física. ou seja, aplicando a tradução fracionária aos comandos de gráficos vetoriais em vez de textura rasterizada.

A correção virá em duas partes:

1. A primeira parte que permite que nosso sistema raster seja rasterizado com qualquer matriz geral. Esta parte está quase concluída. Eu tenho um WIP, mas ainda tem um bug que causa regressão de desempenho. Espero terminar dentro de alguns dias.
   https://codereview.chromium.org/2075873002/
2. A segunda parte permite que nosso gerenciamento de ladrilhos seja capaz de gerenciar um conjunto de texturas que vem com diferentes traduções rasterizadas. Eu estava originalmente indo para a matriz geral, mas descobri que o cálculo da cobertura do bloco se tornou muito difícil. Em vez disso, vou fazer uma versão mais simples que só oferece suporte a tradução e escala. Calculo que isso precise de mais uma semana de trabalho.

Vou tentar pousar no ramal M53, mas o tempo é curto. Tenho certeza de que isso pode ser consertado pelo M54.

https://bugs.chromium.org/p/chromium/issues/detail?id=600120

Para o relator do bug:

O caso de teste que você carregou acionou um caso extremo no Chromium em que lidamos com o encaixe de pixels de uma maneira diferente. Se você adicionar algum conteúdo aos ladrilhos, não verá mais costuras no fundo. Podemos facilmente consertar o caso da borda, no entanto, ainda pode haver falhas no conteúdo do ladrilho.

Este é um problema difícil, e a única solução perfeita conhecida é usar FSAA, o que nenhum navegador faz devido aos custos de CPU / memória. Cada fornecedor desenvolve sua própria heurística para fazer alguns conteúdos parecerem mais agradáveis, às custas de alguns conteúdos parecerem incorretos.

Por exemplo: http://jsbin.com/wayapiz/

O Chrome desenha com a geometria certa, mas as bordas sangram como um porco preso.
O Firefox desenha a primeira caixa como 49x49, a segunda caixa como 49x50.
O Edge desenha a primeira caixa como 50x50, a segunda caixa como 50x49. Ambos com aliasing.

Além disso, se você adicionar rotação ao contêiner, toda a implementação sangrará nas bordas.

Minha solução alternativa recomendada é adicionar alguma sobreposição entre os ladrilhos. Você sabe, como fazer um pôster com papéis A4. A ideia é fazer com que cada ladrilho se sobreponha a pelo menos um pixel após todo o dimensionamento, para que cada pixel físico seja coberto por pelo menos um pixel opaco. A largura da sobreposição depende da menor escala que você deseja suportar. Por exemplo, se você deseja suportar até 1/4 do tamanho, adicione 4 pixels de sobreposição.

Abaixo estão as análises detalhadas para outros desenvolvedores que desejam resolver isso.

O repro carregado pelo repórter não foi um repro muito bom porque dispara um caminho de código otimizado em cc. Quando detectamos uma camada de cor completamente sólida, nós a desenhamos como SolidColorLayerImpl, que não tem o conceito de escala de conteúdo. Aqui está uma reprodução simplificada: http://jsbin.com/hodoxew/

A caixa preta será desenhada como um SolidColorLayerImpl de tamanho (100, 100), que irá gerar um único quadrante de cores sólidas de tamanho (100, 100), que será projetado na tela por transformação de desenho para se tornar (99,5, 99,5). Com o anti-alias, a coluna mais à direita e a linha inferior de pixels serão desenhadas em semitransparente.

Por outro lado, se adicionarmos algo à camada para induzir o cc a pensar que a camada é de cor não sólida, agora o problema surge em dois casos:

1. O último ladrilho tem uma cor sólida, por exemplo: http://jsbin.com/zexawa/

O tamanho do conteúdo será arredondado para cima, portanto, embora o tamanho da camada dimensionada seja apenas (600, 300) * 0,995 = (597, 298,5), ele será sobreposto como (597, 299).

1. O ladrilho da lista não tem cor sólida, por exemplo: http://jsbin.com/mewaguf/

O tamanho do conteúdo será arredondado para cima. Novamente, o conteúdo real dimensionado cobre apenas (600, 300) * 0,995 = (597, 298,5), os quadrantes gerados cobrirão (597.299). A última linha de pixels deve ser semitransparente devido ao anti-alias, mas na verdade a preenchemos com a cor de fundo da camada, que é a cor de fundo do elemento que criou a camada.

Não haverá costura no fundo, entretanto, o fundo pode sangrar nas bordas quando o conteúdo deveria cobri-lo. Por exemplo: http://jsbin.com/vigufo/

Um outro caso de teste, usando blocos de cores não sólidas:
http://playground-leaflet.rhcloud.com/giqo/edit?output

@hyperknot atualização fantástica, mas essas duas citações parecem se contradizer (em uma, uma pessoa diz que está trabalhando em uma correção, e a próxima diz que não é possível uma correção boa). Então, esperamos por uma solução ou apenas aceitamos que será assim para sempre?

@mourner, desculpe, não incluí o contexto completo, e você está certo, é claro. Portanto, o relatório de bug original foi:
https://bugs.chromium.org/p/chromium/issues/detail?id=600120

Em um ponto, ele foi mesclado com outro problema:
https://bugs.chromium.org/p/chromium/issues/detail?id=521364

Nesse outro problema, obtivemos a resposta longa original com uma solução. Eu perguntei se ele poderia verificar se o caso do Folheto é realmente corrigido pelo seu trabalho e ele respondeu:

Lamento que o assunto do folheto seja, na verdade, um problema diferente. Vou reabrir a edição 600120 e compartilhar minha análise.

O bug do Folheto foi reaberto e obtivemos a 2ª resposta no bug do Folheto. BTW, a atualização mais recente agora é:

Dei uma olhada no mapa do Google móvel para ver como eles lidavam com isso. Acontece que eles também são afetados por esse problema, mas fizeram alguns truques de interface do usuário para torná-lo menos óbvio.

A primeira coisa é que eles usaram a tag viewport para impedir o zoom de aperto do navegador e implementaram o zoom de aperto em JS. Durante o zoom pinch, você ainda pode ver as junções entre os blocos (muito sutil em telas de alta resolução). Após a conclusão do gesto de zoom, eles ajustam o fator de escala para o conjunto de blocos mais próximo que possuem. Basicamente, os blocos são sempre exibidos em resolução nativa, exceto durante o gesto de zoom.

Honestamente, ainda não temos um plano sólido. Vou discutir com outras pessoas da pintura na segunda-feira.

BTW, parece que o Google Maps para celular (acho que o do site) está usando exatamente a mesma técnica que nós.

@mourner @IvanSanchez alguma questão fundamental com uma possível solução usando vontade de mudança:
https://bugs.chromium.org/p/chromium/issues/detail?id=600120#c15

A estratificação atual é importante? Vejo que cada bloco é forçado em sua própria camada (translate3d) e essas camadas são dimensionadas por algum valor fracionário independentemente.

Contanto que dimensionemos cada bloco do mapa independentemente (usando camadas ou via drawImageRect + CTM fracionário), para valores de escala fracionária obtemos bordas que não estão alinhadas com pixels. Isso aciona o problema de suavização de borda coincidente ole, em que o AA discreto causa sangramento da cor de fundo.

Acho que isso poderia funcionar em vez disso, rasterizando o mapa com uma escala não fracionária (digamos 1,0) e depois diminuindo a escala atomicamente:

1) evite a estratificação individual de blocos (use "transform: translate ()" em vez de "transform: translate3d ()")
2) forçar a estratificação do contêiner (mapa inteiro) (use "transform: scale3d ()" no contêiner)
3) forçar a rasterização da camada do recipiente com uma escala == 1,0

Com essas alterações, as imagens dos blocos do mapa devem ser rasterizadas com uma escala de 1,0 (=> as bordas são alinhadas em pixels => sem artefatos de emenda) e, em seguida, toda a camada do mapa deve ser reduzida atomicamente.

Infelizmente, o nº 3 não é trivial, e o único hack em que consigo pensar é

• comece com scale (1) e will-change: transform (consulte https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ufwrhx_iZ7U para obter detalhes)
• redefina a escala da camada para o valor desejado após a primeira passagem raster

por exemplo, http://jsbin.com/yaqeru/10/embed?output

chrishtr / danakj entendi corretamente a semântica da escala de rasterização da camada e existe uma maneira melhor de bloquear a escala de rasterização da camada para um valor específico?

Você pode ajudar a responder?

Eu sei que uma correção está em andamento (obrigado a todos por insistir nisso!), Mas enquanto isso ... @cmulders 'monkeypatch funciona melhor para mim. Aqui está uma versão que traz o Leaflet como um módulo npm, usa ES6 e não garante nenhum patch duplo, no caso de alguém estar procurando por alguma coisa boa do copypasta.

https://gist.github.com/ericsoco/5712076f69f9068b11d41262b9e93666

import leaflet from 'leaflet';
// ...
patchMapTileGapBug();
// ...
function patchMapTileGapBug () {

    // Workaround for 1px lines appearing in some browsers due to fractional transforms
    // and resulting anti-aliasing. adapted from <strong i="9">@cmulders</strong>' solution:
    // https://github.com/Leaflet/Leaflet/issues/3575#issuecomment-150544739
    let originalInitTile = leaflet.GridLayer.prototype._initTile;
    if (originalInitTile.isPatched) return;

    leaflet.GridLayer.include({
        _initTile: function (tile) {
            originalInitTile.call(this, tile);

            var tileSize = this.getTileSize();

            tile.style.width = tileSize.x + 1 + 'px';
            tile.style.height = tileSize.y + 1 + 'px';
        }
    });

    leaflet.GridLayer.prototype._initTile.isPatched = true;

}

Fico feliz que as pessoas estejam investigando isso. Caso seja útil para qualquer pessoa como uma solução alternativa menos ideal: se você estiver disposto a sacrificar a inércia, definir intertia:false no mapa, o init elimina as lacunas e, possivelmente, zoomAnimation:false

Acho que encontrei uma solução (complicada demais) para isso, coloquei em https://github.com/Leaflet/Leaflet.TileLayer.NoGap - comentários são bem-vindos, pois não tenho certeza do desempenho dessa coisa em computadores / telefones antigos.

cc @Eschon @hyperknot

BTW, o bug também acontece quando se usa o Chrome em uma tela de alto DPI (2560x1140), sem a necessidade de usar zoom fracionário de folheto nem zoom de navegador.

Desculpe pelo atraso na resposta.

Acabei de testar sua solução. A demonstração funcionou bem para mim, então tentei adicionar a correção ao meu aplicativo. Como eu ainda estava usando uma versão 1.0-dev antiga do Leaflet, atualizei para 1.0.0-rc3 em http://leafletjs.com/download.html

A primeira coisa que notei é que parece haver um erro aqui . Ele mostra um erro naquele mapa indefinido, então mudei para this._map .

Depois disso funcionou, mas é muito lento no meu computador de trabalho. Especialmente no Chrome, mas o Firefox também era lento.

Surpreendentemente, não teve um grande impacto nos telefones que testei.
O Firefox no Android parece ser o mesmo de antes, o Chrome é um pouco mais lento, mas não muito ruim.
O Safari no iOS também parece ser o mesmo de antes.

Outra coisa estranha que notei é que no Chrome para dispositivos móveis e no Safari, o zoom parece ajustar-se a níveis fixos

@Eschon Obrigado por testar isso!

Sempre cometo o erro de digitar map vez de this._map :-(

Depois disso funcionou, mas é muito lento no meu computador de trabalho. Especialmente no Chrome, mas o Firefox também era lento.

Você poderia rodar algum profiler naquele computador? Seria bom saber se a lentidão está relacionada às operações do canvas. Percebi que houve um pequeno impacto no desempenho do IE9-IE11.

Com base no fato de essa solução tornar o mapa mais lento em algumas plataformas, pode fazer sentido torná-lo totalmente opcional e desativado por padrão. Alguns comentários aqui são importantes!

Eu realmente não vi como o pessoal do OL3 resolve esse problema, ou se eles fazem alguma detecção de desempenho no navegador antes de habilitar a composição da tela. Pode valer a pena dar uma olhada.

Outra coisa estranha que notei é que no Chrome para dispositivos móveis e no Safari, o zoom parece ajustar-se a níveis fixos

Aposto que isso é apenas brincar com as opções zoomDelta e zoomSnap , e não está relacionado a esse bug.

Você poderia rodar algum profiler naquele computador? Seria bom saber se a lentidão está relacionada às operações do canvas. Percebi que houve um pequeno impacto no desempenho do IE9-IE11.

Devo apenas registrar um perfil de CPU JavaScript com as ferramentas de desenvolvimento do Chrome? Não tenho muita experiência com esse material de teste de desempenho, então realmente não sei o que fazer com os dados que ele mostra.

Sim, é isso. Em seguida, procure por coisas amplas no gráfico de degradê.

Acabei de fazer um perfil com a correção e outro sem. Tentei fazer o mesmo para os dois perfis.

A primeira coisa que notei que a versão com a correção tinha um "pico" adicional (não sei se essa é a palavra certa) causado por _onZoomTransitionEnd

Na versão sem a correção _onZoomTransitionEnd demorou 1,8 ms e eu nem vi no gráfico. Na versão com a correção demorou 6ms e causou um "pico" de atividade.

Os outros dois "picos" parecem muito semelhantes nos dois perfis, as coisas parecem acontecer um pouco diferentes, mas a lacuna entre eles é maior na versão com a correção.

Espero que te ajude de alguma forma. Eu também salvei os dois perfis para que se você precisar deles, eu poderia carregá-los em algum lugar.

Por enquanto, como uma solução suja, acabei de adicionar um fator de escala de .002 à função original que define a propriedade translate3d para cada bloco, o que elimina as lacunas quase totalmente. "0,002" foi o fator de escala mais baixo em meus casos de teste para fazer as lacunas desaparecerem completamente. Não notei nenhum efeito colateral.

Testado no último Chrome, Firefox e IE 11. Testado em um monitor 4k de 40 "com escala de janela definida para 150% com vários valores de zoom nos navegadores.

algum progresso neste bug? @AlexanderUhl sua solução causa alguma modificação nas imagens quando colocadas ou isso só é afetado durante o movimento / zoom?

Parece que will-change propriedade CSS foi adicionada para resolver este problema, só precisa verificar os avisos de desempenho FF, descritos aqui: https://github.com/Leaflet/Leaflet/issues/4686

@themre : a propriedade scale se aplica a todos os ladrilhos de imagem quando adicionados e são permanentemente. O estilo attr será parecido com este:
style="width: 256px; height: 256px; transform: translate3d(545px, 745px, 0px) scale(1.002); opacity: 1;"

Mas isso faria com que a imagem ficasse um pouco esticada, o que é um efeito indesejado. Tentei a versão 1.0.3 que tem a propriedade CSS will-change mas ainda causa um espaço em branco. Vou tentar olhar mais um pouco.

Ofc estica o img, essa é a abordagem ;-) Concordo que essa solução alternativa não é ideal, mas tbh essa geralmente é a natureza de uma solução alternativa, não é? No entanto, essa abordagem está funcionando melhor para mim com efeitos colaterais insignificantes (para meu caso de uso que é um aplicativo de mapeamento com blocos do mapbox, aqui, osm etc.)

bem, se usarmos o translate normal, o problema desapareceu. Não sei realmente se a propriedade CSS translate3d é muito mais rápida do que o translate normal, talvez seja melhor adicionar este sinalizador como uma opção. Acho que vou substituir o translate3d por translate.

ver em ação:

Enfrentando o mesmo problema, com a versão mais recente (1.0.3).

será corrigido em 1.1, possivelmente

Em 2017, 8 de março, quarta-feira às 10:13, Gaurav [email protected] escreveu:

[imagem: imagem]
https://cloud.githubusercontent.com/assets/13112509/23697357/7dcc4cf6-040d-11e7-881a-df3a44254015.png
Enfrentando o mesmo problema, com a versão mais recente (1.0.3).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Leaflet/Leaflet/issues/3575#issuecomment-284987808 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAeKj_23QbtFCaXeFjGRJcU-jg0284xBks5rjnEvgaJpZM4FO8Jh
.

Se os valores de nx e ny, que são usados ​​para traduzir a div .leaflet-pane.leaflet-map-pane div forem arredondados para um número inteiro, o problema de linha / lacuna será resolvido no Safari. Não consigo ver nenhum efeito colateral prejudicial (para meu uso, de qualquer maneira).

Encontre isto:
translate3d("+n.x+"px,"+n.y+"px,0)")
e substitua por:
translate3d("+Math.round(n.x)+"px,"+Math.round(n.y)+"px,0)")

@LudwigBogner provavelmente falhará de qualquer maneira depois que você fizer alguns ajustes de escala (configuração do zoom do navegador, por exemplo, ou durante a animação de zoom). Veja este exemplo, com link acima, onde as traduções em si são arredondadas:

Só fui mordido por este. Para mim, parece não existir no Chromium ou FireFox. Apenas alguns dos zooms fracionários no Safari.

Progresso?

Este problema ainda existe no Chrome e Firefox (Mac). Estou usando zoomDelta e zoomSnap de 0,25.

Curiosamente, definir .leaflet-tile { will-change: auto !important; } (ou "não definir") corrige o problema no Firefox (apenas). Ainda estou procurando uma solução alternativa para o Chrome.

As outras correções propostas para desativar a inércia e alterar o código translate3d para adicionar arredondamento também não funcionaram.

@jawinn , acho que você pode ter sucesso definindo L_DISABLE_3D para true , IIRC tem quase o mesmo efeito que alterar will-change , ou seja, removerá a aceleração de hardware ao renderizar o mapa. Esteja ciente de que provavelmente terá um desempenho muito pior para animações de zoom, panorâmicas, etc.

Tudo isso é muito sensível aos detalhes de implementação do navegador, então leve isso com atenção, já faz um bom tempo desde que eu olhei para isso.

@jawinn
A solução que utilizo é a de

/* 
 * Workaround for 1px lines appearing in some browsers due to fractional transforms
 * and resulting anti-aliasing.
 * https://github.com/Leaflet/Leaflet/issues/3575
 */
(function(){
    var originalInitTile = L.GridLayer.prototype._initTile
    L.GridLayer.include({
        _initTile: function (tile) {
            originalInitTile.call(this, tile);

            var tileSize = this.getTileSize();

            tile.style.width = tileSize.x + 1 + 'px';
            tile.style.height = tileSize.y + 1 + 'px';
        }
    });
})()

Não é perfeito, mas pelo que posso dizer não afeta o desempenho

Obrigado rapazes. @Eschon Isso funcionou. Não há mais lacunas aparecendo no Chrome ou Firefox.

Para quem vai usar a "correção de 1px", esteja preparado para que suas imagens fiquem borradas e um pouco quebradas:

• comparação 1: https://diff.pics/RJC_xRHl8aCX/1
• comparação 2: https://diff.pics/8zvB6-PHdqLm/1

Para mim, que passava horas renderizando e fazendo fotos da imagem original, isso era inaceitável. Então, eu tive que usar L_DISABLE_3D = true e aguentar com animações piscando e zooms saltitantes no final.

Mais informações: Eu uso o plugin leaflet-rastercoords e minhas configurações de mapa são as seguintes:

    map = L.map('map', {
        center: [3250, 1700],
        zoom: 5,
        minZoom: 2,
        maxZoom: 6,
        maxBoundsViscosity: 1,
    });

P: Qual é a próxima melhor alternativa para o Folheto que não tem esse bug de "espaço entre as peças"?

Eu mesmo vou pesquisar no Google, mas talvez alguém já tenha trilhado esse caminho.

@ n3tman você também experimentou o plugin NoGap ? Pode valer a pena tentar.

@perliedman obrigado por mencionar este.
Infelizmente, não foi possível fazê-lo funcionar localmente. Erro Cannot read property 'appendChild' of undefined na função _initContainer .
Tentei com versões anteriores do folheto (até 1.0.2) - mesmo resultado. A demonstração mostra o mesmo erro no Chrome / Firefox.
Talvez eu esteja faltando algo óbvio, você pode ajudar?

O mesmo intervalo de 1px aqui.

Versão do Chrome 66.0.3359.139 (64 bits)
Windows 10 (1709)
Folheto 1.3.1

Quando abri este problema inicialmente, descobri que ele está relacionado a níveis fracionários de zoom, mas essa pode não ser mais a única causa.

Recentemente, comecei um projeto que usa o plug-in GoogleMutant e aí descobri que isso também acontece quando eu apenas configuro o nível de zoom para um número inteiro e movo um pouco.

Parece estar relacionado ao # 6069 e (mais ou menos) corrigido pelo # 6240, embora as lacunas ainda apareçam durante o zoom e a panorâmica.

Eu também removi a solução alternativa de meus outros projetos e parece acontecer lá também, então não é específico para o plugin GoogleMutant

Inspirado na solução alternativa de @cmulders 1px ... Funciona, mas o efeito desfocado que aparece não é bom em algumas imagens. Em vez disso, tentei o seguinte (embora não testei muito ...) e parece corrigir as lacunas e ainda manter as imagens nítidas com níveis de zoom não fracionários. O 0,5 px adicional parece ser suficiente para cobrir as lacunas (tentei Chrome e Firefox no Linux e Chrome no Android, com o folheto 1.3.4)

(function(){
    var originalInitTile = L.GridLayer.prototype._initTile
    L.GridLayer.include({
        _initTile: function (tile) {
            originalInitTile.call(this, tile);

            var tileSize = this.getTileSize();
            var map = this._map;
            var isFix = function() {
                return !(parseFloat(tile.style.width) % 0 === 0);
            };
            var fixOn = function() {
                if(!isFix()) return;
                tile.style.width = tileSize.x + 0.5 + 'px';
                tile.style.height = tileSize.y + 0.5 + 'px';
            };
            var fixOff = function() {
                if(isFix()) return;
                tile.style.width = tileSize.x + 'px';
                tile.style.height = tileSize.y + 'px';
            };
            var checkFix = function(){
                var zoom = map.getZoom();
                if(zoom % 1 === 0) {
                    fixOff();
                }
                else {
                    fixOn();
                }                
            };
            map.on('zoomstart',fixOn);
            map.on('zoomend',checkFix);
            checkFix();
        }
    });
})()

Mais de 3 anos depois, esse bug ainda não foi resolvido no Chrome! Não vejo o efeito no Firefox ou Safari. Obrigado @cmulders pelo seu trabalho!

O mesmo aqui (Windows 7 Enterprise SP1). Linhas aqui e ali no Firefox, grade de linha completa no Chrome, mas OK no IE11. A correção

Aqui estão os resultados completos de mais alguns testes:

• Windows 7 Enterprise SP1
  
  
  
  • IE11: OK
  
  
  • Chrome, Firefox: não está OK
  
  
• Windows 10
  
  
  
  • IE11, Edge, Firefox: OK
  
  
  • Chrome: não está bem
  
  
• Mac OS
  
  
  
  • Safari, Chrome, Firefox: OK
  
  
• Linux:
  
  
  
  • Chrome, Firefox: OK
  
  
• Android:
  
  
  
  • Chrome, Firefox: OK
  
  
  • Aplicativo usando WebView: OK
  
  

Testes posteriores mostraram que este é obviamente um problema de nível muito baixo que não tem nada a ver com o folheto.
O teste no Windows 7 Enterprise SP1 foi inicialmente em dois PCs diferentes, mas ambos com placa de vídeo NVIDIA.

Quando o mesmo teste foi feito no Windows 7 Enterprise SP1 com gráficos AMD Radeon, deu certo, sem linhas entre os blocos no Chrome ou Firefox!

Como o NoGap foi mencionado antes, eu só queria que você soubesse que peguei o código original e o modifiquei para fazê-lo funcionar com as versões atuais do folheto (ou seja, folheto ^ 1.3.3):
https://github.com/Endebert/squadmc/blob/master/src/assets/Leaflet_extensions/NoGapTileLayer.js

Ele pode então ser usado como um TileLayer normal: https://github.com/Endebert/squadmc/blob/master/src/assets/SquadMap.js#L34

Ele está usando as funcionalidades do es6, então talvez seja necessário fazer algumas modificações para que funcione para você.

Como o NoGap foi mencionado antes, eu só queria que você soubesse que peguei o código original e o modifiquei para fazê-lo funcionar com as versões atuais do folheto (ou seja, folheto ^ 1.3.3):
https://github.com/Endebert/squadmc/blob/master/src/assets/Leaflet_extensions/NoGapTileLayer.js

Ele pode então ser usado como um TileLayer normal: https://github.com/Endebert/squadmc/blob/master/src/assets/SquadMap.js#L34

Ele está usando as funcionalidades do es6, então talvez seja necessário fazer algumas modificações para que funcione para você.

@Endebert Você conseguiu fazer o NoGap funcionar? Recebi o mesmo erro de @ n3tman há algum tempo:
Cannot read property 'appendChild' of undefined erro na função _initContainer .

A única alteração que encontrei em sua versão foi adicionar try ... catch à chamada level.ctx.drawImage(imageSource, offset.x, offset.y, tileSize.x, tileSize.y);
e não ajudou.

@TomazicM Sim, minha implementação está sendo usada em meu aplicativo SquadMC . Pode não ser tão óbvio no desktop, mas no celular é evidente que o zoom fracionário sem ajuste está ativado.

Em relação à implementação: A versão original usa TileLayer.include() , enquanto eu uso TileLayer.extend() . Acredito que essa seja a diferença importante. Conforme mencionado, é uma nova classe que deve ser usada no lugar de TileLayer.

Bem, aqui está o meu resultado de 2 horas de investigação. O problema é causado por decimais de pixel dentro de translate3d .

<div class="leaflet-pane leaflet-map-pane" style="transform: translate3d(-10.7773px, -8.41406px, 0px);"></div>

É por isso que funciona bem com L_DISABLE_3D = true , pois de acordo com esta parte do código - translate3d .

Solução

Só não permita pixels decimais. Isso pode ser alcançado, por exemplo:

• alterando o construtor Point para sempre arredondar as coordenadas
• ou deslocamento de arredondamento antes de translate3d ser definido

```js
var pos = (offset && offset.round()) || new Point(0, 0);
```

• ou por muitas e muitas outras soluções ...

Bem, aqui está o meu resultado de 2 horas de investigação. O problema é causado por decimais de pixel dentro de translate3d .

Acho que hoje é 2019 e usar translate3d para forçar o uso de GPU de navegador moderno é bastante obsoleto. Bom trabalho @mdorda

@mdorda Hi! Parece interessante, mas esteja ciente de que o arredondamento foi discutido antes neste tópico: https://github.com/Leaflet/Leaflet/issues/3575#issuecomment -327237235

Não tenho certeza se algo importante mudou desde então, isso faz diferença, mas eu não teria esperanças até que tenhamos feito alguns testes completos.

Um primeiro passo para resolver isso seria enviar um PR para que possamos testar isso.

Para aqueles que trabalham com Angular 2+, resolvi desta forma. Funciona para meu caso de uso simples, não sei sobre outras implicações ...

const tileLayer = new TileLayer(this.tileLayerUrlTemplate, this.tileLayerOptions);
tileLayer.on('load', () => {
    for (const tile of Array.from(document.getElementsByClassName('leaflet-tile'))) {
        (<HTMLElement>tile).style.height = (tile.clientHeight + 1) + 'px';
        (<HTMLElement>tile).style.width = (tile.clientWidth + 1) + 'px';
    }
});
this.map.addLayer(tileLayer);

Eu vejo esta lacuna de pixel no zoom fracionário no LeafletJS versão 1.5.1 no Windows 10 Pro 1903 com Mozilla Firefox 69.0.1 (64 bits).
Gap de pixel
Eu acho que a razão do pixel gap talvez não na função CSS translate3d (), mas em scale ().

Na versão 1.5.1, como vejo, os parâmetros de translate3d () são apenas inteiros.

Atenciosamente, IMMSPgisgroup

Você encontrou alguma solução para este bug?

Estou com o mesmo problema neste momento e não encontrei solução.

Estou usando:

• Windows 10 Home 1803
• Google Chrome versão 77.0.3865.90 (versão oficial) (64 bits)
• Folheto 1.5.1

Quando eu uso o Firefox, as linhas brancas não aparecem

@ Arenivar93

Na, estou de olho nisso há alguns anos. Eles tentaram várias soluções alternativas, mas nada funcionou para corrigi-lo sem grandes compromissos. A raiz do problema está no cromo: https://bugs.chromium.org/p/chromium/issues/detail?id=600120

A última mensagem da equipe do cromo é que é muito difícil fazer sem quebrar outras coisas, então podemos ficar presos nisso por um tempo.

Especialmente em mapas ou imagens mais escuras (no meu caso), o problema é bastante perceptível. Eu acho que o antialiasing no navegador causa os espaços entre os tiles devido à transformação _fractional_ durante o zoom, conforme mencionado por Ivan.

Até que uma solução melhor esteja disponível, usarei esta solução alternativa (ou hack) para aumentar os tiles 1 pixel, com o efeito colateral de que eles se sobrepõem em 1 px. Além disso, os blocos serão ligeiramente aumentados e redimensionados (em 1px).

/* 
 * Workaround for 1px lines appearing in some browsers due to fractional transforms
 * and resulting anti-aliasing.
 * https://github.com/Leaflet/Leaflet/issues/3575
 */
(function(){
    var originalInitTile = L.GridLayer.prototype._initTile
    L.GridLayer.include({
        _initTile: function (tile) {
            originalInitTile.call(this, tile);

            var tileSize = this.getTileSize();

            tile.style.width = tileSize.x + 1 + 'px';
            tile.style.height = tileSize.y + 1 + 'px';
        }
    });
})()

tivemos muita sorte com essa solução. não é perfeito, mas é melhor do que as linhas em nossa opinião.

além disso, garantimos que a cor de fundo do mapa estava mais alinhada com a cor do mapa base. por exemplo, se o oceano fosse de um azul escuro, usaríamos isso para que os ladrilhos se sobreponham a essa cor, minimizando algumas das inconsistências que são perceptíveis.

de novo não é perfeito, mas ajuda

@colbyfayock Posso perguntar onde e como você implementa sua solução?

estou construindo um app react, por isso pode ser diferente, mas criei um arquivo com este conteúdo:

// Fix via https://github.com/Leaflet/Leaflet/issues/3575#issuecomment-150544739
import L from 'leaflet';

(function () {
  if (!L || !L.GridLayer || !L.GridLayer.prototype) return;

  var originalInitTile = L.GridLayer.prototype._initTile;

  L.GridLayer.include({
    _initTile: function (tile) {
      originalInitTile.call(this, tile);

      var tileSize = this.getTileSize();

      tile.style.width = tileSize.x + 1 + 'px';
      tile.style.height = tileSize.y + 1 + 'px';
    }
  });
})();

os retornos no topo são porque ele pré-compila e nem sempre está disponível (não é importante aqui)

então estou simplesmente importando depois de importar o folheto

import L from 'leaflet';
...
import '../plugins/leaflet-tilelayer-subpixel-fix';

Minha solução alternativa é arredondar o valor da transformação sem aplicar uma alteração ao código-fonte.
Usando com react, mas pode ser usado por qualquer front end, uma vez que é JQuery
Não dizer é a melhor opção, mas apenas faz com que seja feito.
Isso corrige o problema e eu não observei nenhum desfoque perceptível ou defeito de algum tipo. Vale a pena tentar.

    this.leftMap.on('move', () => {
      const mapDiv = window.document.getElementsByClassName("leaflet-pane leaflet-map-pane")
      let styleString = mapDiv.getAttribute("style");
      const transformValue = styleString.substring(styleString.indexOf("(")+1,styleString.indexOf("px,"));
      const roundedTransformValue = Math.round(parseFloat(transformValue));
      styleString = styleString.replace(transformValue,roundedTransformValue);
      mapDiv.setAttribute("style",styleString);
    });

@colbyfayock - Parece não resolver isso para mim. :(

Estou usando o folheto react com zoom 0.

a solução nunca foi perfeita para nós, mas definitivamente não temos linhas consistentes como essa nas nossas. Eu não tinha certeza sobre o recurso zoomSnap , então tive que procurá-lo, não tenho certeza de como 0 funcionaria com essa propriedade, pelo modo como estou lendo a descrição. você tentou remover isso apenas para ver se as linhas ainda estão presentes sem ele?

https://leafletjs.com/examples/zoom-levels/#fractional -zoom

Editar: continue lendo após o gif de exemplo

zoomSnap pode ser definido como zero. Isso significa que o folheto não ajustará o nível de zoom.

Eu estou supondo que você está entrando em estados fracionários que a solução não consegue lidar além do snap padrão inteiro inteiro 🤷‍♂️mas não tenho certeza

Folheto 1.7-dev e ainda o problema persiste. Linhas nas bordas dos tiles no Firefox e Chrome no Windows 7 e Windows 10. Nenhum problema no IE11 e no antigo (não Crome) Edge, mesmo problema no novo Edge baseado no Chrome.

Existem duas soluções de trabalho, mas não gosto de nenhuma delas. Uma é desabilitar 3D por <script>L_DISABLE_3D = true;</script> , mas isso significa perder operações animadas. Outra é estender os elementos HTML do bloco em 1 pixel, mas isso significa que os blocos ficam levemente desfocados.

Achei uma solução muito primitiva, mas pela própria natureza de ser primitiva, funciona 100%. Talvez alguém ache útil.

A solução é exibir a mesma camada de ladrilhos ofensiva duas vezes em dois painéis de mapa diferentes, um colocado abaixo do outro e tendo deslocamento [-1, -1].

O código é parecido com este:

<style>
  .originOffset {
    transform: translate(-1px, -1px);
  }
</style>

<script>
  var pane1 = map.createPane('pane1');
  var pane2 = map.createPane('pane2');

  pane1.style.zIndex = 210;
  pane2.style.zIndex = 220;

  L.DomUtil.addClass(pane1, 'originOffset');

  var layer1 = L.tileLayer( ... , {
    pane: 'pane1',
    ...
  });
  var layer2 = L.tileLayer( ... , {
    pane: 'pane2,
    ...
  });
  var layer = L.layerGroup([layer1, layer2]);
</script>

da sugestão de @cmulders, adiei essas linhas e não há mais espaço entre os blocos

map.on ('zoomend drag', function () {
$ ('# map> div.leaflet-pane.leaflet-map-pane> div.leaflet-pane.leaflet-tile-pane> div> div> img'). each (function () {
if (String ($ (this) .css ("largura")). includes ('. 5') === false) {
var imgW = String ($ (this) .css ("largura")). split ("px") .join (".5")
var imgH = String ($ (this) .css ("height")). split ("px") .join (".5")
$ (este) .css ("largura", imgW);
$ (este) .css ("altura", imgH);
}
});

Estou com @mdorda , quando a panorâmica e o zoom resultam em números inteiros na chamada de leaflet-map-pane para translate3d() , em vez de frações de pixels, então (com minhas vendas) o problema desaparece e tudo é lindo de novo. Não pretendo compreender todas as nuances de quando as frações precisam ser mantidas, mas se isso fornecer ao Leaflet algum alívio para o problema do navegador, seria aceitável colocar L.Draggable._onMove em algum piso

    offset.x = Math.floor(offset.x / this._parentScale.x);
    offset.y = Math.floor(offset.y / this._parentScale.y);

ou mesmo em L.DomUtils.setTransform

    pos.x = Math.floor(pos.x);
    pos.y = Math.floor(pos.y);

de modo que nenhuma tradução recebe frações, mas isso provavelmente seria um desperdício, já que as imagens de bloco não resultam em traduções fracionárias (certo?).

Eu perdi duas horas para descobrir depois que as configurações do meu navegador foram ampliadas, não em tamanho real
Basta levar o zoom de volta ao real e tudo funcionou perfeitamente, esse foi o meu caso

Eu perdi duas horas para descobrir depois que as configurações do meu navegador foram ampliadas, não em tamanho real
Basta levar o zoom de volta ao real e tudo funcionou perfeitamente, esse foi o meu caso

@tokenflow : este tópico é literalmente sobre 'Espaço entre blocos em níveis de zoom fracionários em navegadores Webkit'. Estou realmente tentando não ser arrogante aqui, mas você realmente acha que suas informações sobre zoom para 100% são uma contribuição útil para alguém?

Eu encontrei esse bug na versão Linux do Firefox e do Chromium.
O problema (pelo menos para o Firefox) parece ser scale() do .leaflet-tile-container , que consegui encontrar com document.querySelector('.leaflet-tile-container:last-of-type').getAttribute('style') .
Por exemplo. você tem scale(0.707107) , mas todos os filhos img têm largura / altura 256. Então você calcula: 0.707107 * 256px = 181.019392px , que é um número decimal. Quando você então arredonda os pixels e toma isso como escala, parece funcionar no Firefox / Linux: 181px / 256px = 0.70703125 .

Escrevi uma função que ajuda a depurar:

function getCurrentScale (doFix = false) {
    const tileContainer = document.querySelector('.leaflet-tile-container:last-of-type');

    if (!tileContainer) {
        return;
    }

    const tileStyle = tileContainer.getAttribute('style');
    const scaleRegEx = /scale\(([0-9\.]+)\)/i;
    const matches = scaleRegEx.exec(tileStyle);

    if (!matches || matches.length !== 2) {
        return;
    }

    const scale = parseFloat(matches[1]);

    const mod = (scale * 256) % 1;

    if (mod) {
        console.log('scale is off by px:', mod);
        if (doFix) {
            const newScale = Math.round(scale * 256) / 256;
            console.log('old scale / new scale', scale, newScale);
            const newStyle = tileStyle.replace(scaleRegEx, `scale(${newScale})`);
            tileContainer.setAttribute('style', newStyle);
        }
    } else {
        console.log('scale seems to be fine:', scale);
    }
}

Se você chamá-lo com true como o primeiro parâmetro, ele tenta consertar a escala. Isso, no entanto, só funciona no Firefox para mim.

Eu encontrei uma solução que é estúpida e realmente não deveria funcionar.

.leaflet-tile-container img {
    width: 256.5px !important;
    height: 256.5px !important;
}

Isso deve resultar em emendas enormes ao redor dos ladrilhos, mas não consigo vê-los de jeito nenhum e isso corrige o espaço entre os ladrilhos.

@ ChrisLowe-Takor, de alguma forma, realmente parece funcionar, embora à primeira vista eu não consiga dizer por quê.
Isso pode ser preferível à solução alternativa de JavaScript que estou usando agora, mas terei que examiná-la um pouco mais e fazer alguns testes, mas.

@ ChrisLowe-Takor - Uau, funciona para mim também! Bom achado 👍

@ ChrisLowe-Takor também parece funcionar para mim no R, usando o pacote-folheto. Muito obrigado!

@ ChrisLowe-Takor De alguma forma, esse truque realmente funciona para todos os navegadores modernos estúpidos (para o velho e venerável IE11, ele não é necessário)! Há apenas uma coisa a se ter em mente: se a opção detectRetina for usada para a camada de bloco e a tela for retina, o tamanho do bloco será 125 x 125 px.

Mas essa solução tem a mesma desvantagem de todas as soluções baseadas na expansão do contêiner de ladrilhos: o ladrilho fica um pouco borrado.

@ ChrisLowe-Takor eu tentei. Se maxZoom for maior que maxNativeZoom, os blocos não serão exibidos corretamente.