Editor ID lento

Caros,

em dois computadores que o testei, o editor ID funciona muito lento.
Alguém tem uma dica do que pode ser?

Grato, Linhares

specs?

O iD é um editor baseado em JavaScript. Eu sugeriria tentar um navegador com um bom motor de JavaScript, tipo o Google Chrome. Se não funcionar, tentar outros navegadores (Firefox, Opera). A princípio, deve funcionar mais ou menos bem no Safari (mas um pouco mais lento que no Chrome). Não espero que vá funcionar muito bem no Internet Explorer (é menos compatível com tecnologias abertas).

Mesmo assim, ele é de fato um pouco mais pesado que o Potlatch, já que JavaScript é uma linguagem interpretada e sobre ela rodam validações do próprio navegador. Em Flash há outras inconveniências (nem sempre funciona bem em Mac e em Linux, não é mais mantido pra Android), mas onde funciona (praticamente só no Windows) funciona muito bem por causa das otimizações de multimídia (desenho de vetores e de imagens com aceleração por DirectX). A decisão de ir pro JavaScript é pra ter independência de plataforma.

Nunca medi, mas acho que também precisa de um pouco mais de memória RAM que o Potlatch. Sugiro rodar o iD e observar se não tá dando muita paginação (se estiver, a luz de atividade do seu HD vai ficar piscando bem mais do que de costume).

É no windows mesmo. Firefox e Opera. E o computador não é lá grandes coisas.
Vou testar no Chrome. Por enquanto sigo no Potlatch2 :roll_eyes: e no JOSM :sunglasses:

Heh, o JOSM é bem mais produtivo se você conhecer bem os recursos principais, se você se vira bem com ele não tem por que usar o iD, a menos que esteja numa máquina onde não possa instalar aplicações. :sunglasses:

Ou que você queira ajudar os iniciantes, o que é muito bem-vindo e necessário. :smiley:

Verifique se limpar o cache do navegador não melhora algo. O Javascript pode estar se confundindo.

Quais seriam os recursos básicos principais, para utilizarmos o JOSM substituindo o iD?

Olha, abrindo o mapa de Porto Alegre inteira, meu uso de memória pro JOSM fica em 228 MB. O principal limitador mesmo pra trabalhar com grandes volumes de dados é CPU. Trabalho em dois computadores - um Core i7 e um Core i3 - e o Core i3 é um pouco lento pra mapas grandes. O que mais consome processamento é a aplicação de estilos visuais (especialmente ao selecionar grandes quantidades de elementos). Como o JOSM não usa aceleração gráfica, numa máquina mais limitada eu sempre desativo o antialiasing (Preferences > Display Settings > OSM Data > Smooth map graphics). Numa muito limitada, daria pra trabalhar em modo wireframe, mas daí acho que fica meio complicado.

Qual é o sistema operacional?

Quais são os sistemas operacionais?

Não seria por ser Java?

Quanto a questão a seguir:

Por favor, considere respondê-la em users: Brazil » Porque usuários veteranos preferem o JOSM?.

Debian/Linux, ou seja, consome um pouco mais de memória do que consumiria no Windows.

A lentidão gráfica é por ser Java sim. Não fui a fundo mas acho que aceleração gráfica em Java exige APIs que não são padronizadas, talvez por isso não tenham usado.

Bem, nesse outro tópico só tinham falado de razões de usabilidade pró-JOSM. Aqui a questão era a lentidão do iD. Dependendo do computador da pessoa, esses requisitos do JOSM podem ser inclusive uma razão para não usá-lo (o iD consome menos memória e usa a aceleração gráfica do navegador, que geralmente usa a aceleração do próprio sistema operacional; mas, ao contrário do JOSM, o iD não carrega grandes volumes de geometria). Se você quiser, pode copiar essas informações pra lá adaptando como achar que fica mais claro.

Qual gerenciador de janelas? Uso Ubuntu 12.04 com Gnome 3.

Quando conheci o Java, ele era lento até sem interface gráfico. Não ma parece que isso tenha melhorado.

Eu uso o XFCE, é bem mais leve.

O Java anda mais rápido hoje, principalmente se você usar a JRE da Sun. Eles provavelmente fizeram em Java para ser fácil de desenvolver e fácil de rodar em sistemas operacionais diversos. (Imagine o esforço de fazer uma aplicação complexa assim para Windows, Mac e Linux.)

Pode ser uma boa elevar o uso de memória da JRE, de forma semelhante à descrita em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RJ/Rio_de_Janeiro/Import_IPP#Processo_de_convers.C3.A3o:

java -Xmx1048m ...

[]s