Mais Acompanhamento na discussão sobre Alta DPI

Excelente!Que discussão divertida nós estamos tendo sobre Alta DPI.Foi tão enriquecedor que Ryan escreveu um resumo sobre mais uma parte da discussão.Muito obrigado! --Steven

Houve vários comentários postados com relação à alta DPI, junto com algumas discussões animadas. Muito do que foi dito foram bons exemplos de relatos que são consistentes com os dados que nós coletamos. Para as áreas sobre as quais não tínhamos dados, os comentários ajudaram a validar muitas de nossas suposições para esse grupo. Também está claro que algumas áreas desse recurso são confusas e em alguns casos há alguns “mitos" sobre o que é o ideal, o que é possível e o que realmente está lá. Este artigo de acompanhamento é principalmente para resumir o que ouvimos e para fornecer alguns detalhes quanto às áreas que ficaram um pouco confusas.

Aqui está uma lista com nossas principais “suposições”, ecoadas pelos comentários postados:

• A maioria das pessoas ajusta a resolução da tela ou para ver um tamanho de texto maior ou por acidente
• Há um grupo de pessoas que conhece alta DPI e a usa.
• Algumas pessoas preferem uma maior área de tela enquanto outras preferem uma UI maior
• A habilidade de descobrir as configurações DPI é uma preocupação para alguns
• A compatibilidade entre aplicativos é um problema comum, até um “estraga prazeres” às vezes.
• O Dimensionamento do IE é um dos problemas mais importantes (vejam o IE8, que corrige muitos deles!)
• Há muitas complexidades/sutilezas é e muito difícil explicar esse recurso para a maioria das pessoas

Também houve várias áreas um pouco confusas:

• É verdade que se tudo fosse baseado em vetores esses problemas desapareceriam?
• Isso não deveria simplesmente funcionar sem que os desenvolvedores precisassem fazer nada?
• Qual a diferença com relação ao dimensionamento por aplicativo como o zoom do IE?
• A DPI deveria funcionar por calibragem ou por dimensionamento?

A maioria desses tópicos foi discutida de alguma forma nos comentários, mas já que há tanto interesse, decidimos nos aprofundar em algumas questões/assuntos mais importantes.

Gráficos Vetoriais versus Gráficos de Varredura

Sempre há a esperança com os PCs de que surja uma tecnologia "simples e garantida" que resolva todos os problemas tornando a vida de todos os usuários, desenvolvedores e designers mais fácil. Por exemplo, alguns dos comentários no artigo original sugeriram que se nós fizéssemos o OS totalmente baseado em vetores, esses problemas de dimensionamento desapareceriam. Acontece que há vários problemas em utilizar gráficos vetoriais que não valem a pena explicar.

O primeiro problema é que, às vezes, quando um ícone é pequeno é melhor usar uma representação alternativa a fim de que o significado permaneça claro. Vejam os ícones abaixo. Nesse caso, o designer escolheu uma visão não-perspectiva para o ícone quando ele é mostrado em seu menor tamanho.

 

Isso acontece porque o designer achou que a informação passada pelo ícone seria mais clara com uma visão direta no menor tamanho. Aqui está outro exemplo ilustrando esse ponto:

 

Claro, isso significa que o designer deve criar múltiplas versões de design da imagem fonte, então há uma complexidade adicional. A questão aqui é que existe uma compensação a ser feita esta compensação nem sempre é evidente.

Mesmo quando uma fonte vetorial é utilizada, é comum fazer adaptações de tamanho a fim ter a certeza de que o resultado corresponde ao que o designer tinha em mente. Imagine um gráfico vetorial que possui uma linha de 1 pixel a 128x128 que seja reduzida pela metade para 64x64. A tela não tem como mostrar uma linha perfeita de 1/2 pixel! Em muitos casos, a resposta é que o processador irá “arredondar” para uma linha pixel próxima. Entretanto, fazer isto inerentemente altera o layout dos sub-elementos da imagem. Há também a questão: “para qual linha de pixel arredondar?”. Se o designer não ajustar à mão o material fonte, ficará a cargo do mecanismo do processador tomar essa decisão, e isso pode resultar em efeitos indesejáveis. Poderíamos dizer que isso deve portanto definir regras sobre quais elementos devem ser utilizados num vetor, mas isso somente restringe quais conceitos podem ser representados.

Acontece que até as fontes TrueType que usamos no Windows são ajustadas à mão com informações de tamanho a fim de dar ao resultado a mais alta qualidade possível. A maioria dos pipelines de processador TrueType é baseada em dimensionamento algorítmico de uma fonte vetorial, mas são "dicas" tamanho-dependentes e codificadas à mão em TrueType as quais o designer especifica para orientar o sistema sobre como lidar com casos extremos, tais como linhas ficando entre fronteiras de pixels. Aqui está um link que descreve isso em mais detalhes: https://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

Não é verdade que gráficos vetoriais são necessariamente menores em tamanho (especialmente para imagens pequenas). A maioria dos designers cria gráficos usando um editor que constrói uma imagem utilizando várias camadas de desenhos e efeitos. Com gráficos baseados em bitmaps, os designers “achatam” as camadas antes de adicioná-las a uma parte de um software. Hoje a maioria dos designers presta pouca atenção ao tamanho das camadas porque o processo de achatamento essencialmente as converte num tamanho fixo com base na resolução da imagem. Com gráficos vetoriais, não há tal técnica de achatamento, então os designers precisam pensar cuidadosamente nas ferramentas que utilizam e os efeitos que eles adicionam para ter certeza que o ícone não vai ficar extremamente grande. Passei algum tempo com um de nossos designers, o qual tinha uma fonte gráfica vetorial para um de nossos bitmaps no Windows e o arquivo tinha 622k! Claro que o tamanho do arquivo é fixo independentemente da resolução final, mas aquele arquivo enorme fica achatado num bitmap PNG de 23k.

Claro que sua representação à mão baseada em vetores provavelmente poderia ser diminuída se as restrições de tamanho fossem parte do processo de tempo do design. Mas essa seria uma restrição adicional para o designer, uma que teriam que aprender a realizar bem.

Como podemos ajudar os programadores?

Para aplicativos que precisam controlar cuidadosamente o layout e parte gráfica, ou dimensionar a fidelidade das imagens com base na resolução disponível, é importante ter uma maneira de determinar localizações de pixels específicas de itens para obter o melhor resultado. Isso é tão verdadeiro para o Mac quanto para o PC (ver https://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/). Às vezes há uma crença de que se nós fornecêssemos as ferramentas certas ou a estrutura certa, então todos esses problemas desapareceriam. Todos nós sabemos que cada grupo de ferramentas e cada estrutura têm seu próprio conjunto de compensações (sejam elas Win 32, .net ou HTML). Apesar de não haver uma solução completa e simples, existem coisas que podemos fazer a fim de que escrever aplicativos sensíveis a DPI seja mais fácil para os desenvolvedores. Por exemplo, existem dois importantes eventos futuros do ecossistema nos quais falaremos em detalhe sobre Alta DPI. Também teremos materiais que disponibilizaremos para programadores e que ajudarão a informá-los sobre como converter aplicativos existentes para que reconheçam DPI. O primeiro evento é a Conferência de Desenvolvedores Profissionais da Microsoft, onde falaremos sobre Alta DPI como parte da palestra “Escrever um Aplicativo de Destaque em Hardwares Modernos de Elementos Gráficos" (link). O segundo é a Conferência de Engenharia de Hardware Windows, na qual iremos discutir Alta DPI como parte do evento “Elementos Gráficos e Mídia de Alta Fidelidade" (link).

Ajuda com Problemas de Compatibilidade de Aplicativos

Houve vários artigos sobre compatibilidade de aplicativos e alta DPI (por exemplo, o comentário de bluvg). Também houve comentários discutindo a complexidade e inteligibilidade da configuração Alta DPI. Em alguns casos, os problemas de compatibilidade entre aplicativos podem ser atenuados ao habilitar ou desabilitar o recurso de dimensionamento automático. Isso pode ser alterado globalmente ao ir até a UI DPI, clicar o botão de nome “Personalizar DPI” e alterar a caixa de seleção de nome “Usar escala DPI do estilo do Windows XP”. Quando essa caixa de seleção não está selecionada, os aplicativos que não reconheçam a DPI são automaticamente dimensionados pelo gerenciador de janelas. Quando está selecionada, o dimensionamento automático fica globalmente desabilitado. É interessante notar que para configurações de DPI < 144 DPI, essa caixa está selecionada de forma padrão; para configurações de DPI >= 144 o padrão é não estar selecionada. Em alguns casos, alterar as configurações padrão pode resultar numa experiência melhor dependendo dos aplicativos que você usa e de sua configuração de DPI. Também é interessante notar que o dimensionamento automático pode ser desligado individualmente por aplicativo utilizando as propriedades da Compatibilidade de Programas do Vista. Aqui está um link com mais informações sobre como fazer isso: https://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx. (Veja a seção sobre “Desativar dimensionamento da exibição em configurações de DPI alto”).

Qual a diferença entre dimensionamento DPI e por aplicativo (como o zoom do IE)?

Um aplicativo UI típico é possui uma janela de conteúdo e um quadro de UI. O quadro de UI é onde os itens do menu e botões da barra de ferramentas estão. A janela de conteúdo é o “modo de exibição do documento”. Por exemplo, no IE a janela de conteúdo é a página da web efetiva. Acontece que o código necessário para dar suporte ao dimensionamento em Alta DPI para as janelas de conteúdo é o mesmo código necessário para fazer o recurso de zoom. Na verdade, para a janela de conteúdo o IE8 simplesmente utiliza a configuração de Alta DPI para configurar o fator de zoom padrão (ver Dimensionamento DPI e Internet Explorer 8 para mais detalhes). Entretanto, a Alta DPI tem o efeito colateral adicional de dimensionar o tamanho do quadro de UI. Já que a maioria das pessoas utiliza o recurso de dimensionamento para aumentar o texto e torná-lo mais legível, faz sentido dimensionar o quadro de UI também, já que o texto nos itens do menu e dicas de ferramentas da barra de ferramentas também será dimensionado. De certa forma, se houver um dimensionamento por aplicativo que se trate realmente da área de conteúdo; os aplicativos darão suporte a isso conforme os desenvolvedores observarem a necessidade do cliente. O dimensionamento DPI faz com que os elementos UI de todos os aplicativos pareçam semelhantes.

A DPI não deveria ser utilizada para calibrar a tela (de forma que "uma polegada é uma polegada")?

Alguns sugeriram que nós simplesmente deveríamos usar a Alta DPI como uma forma de calibrar a tela a fim de que o tamanho físico de um objeto seja o mesmo independentemente da exibição. Isso faz muito sentido de uma perspectiva lógica. A idéia seria calibrar a exibição a fim de que “uma polegada seja uma polegada”. Pensamos em fazer isso, mas o problema é que não resolve a necessidade do usuário final de querer ter uma forma de configurar o tamanho do texto e da UI. Se então nós tivéssemos uma “escala global” separada e variável, isso significaria que os desenvolvedores de aplicativos precisariam prestar atenção em ambas as métricas, o que aumentaria a complexidade para os desenvolvedores. Além disso, se um usuário achar que a UI é pequena demais, quem deveria ajustar a preferência quanto ao tamanho da UI: o desenvolvedor ou o usuário? Em outras palavras, se o designer quer que o botão tenha uma polegada, mas o usuário quer que o botão tenha 1,5 polegadas para que seja mais fácil de usar, quem deveria decidir? Da forma que o recurso funciona hoje, fica a cargo do usuário ajustar sua preferência, mas cabe ao desenvolvedor do aplicativo assegurar que a preferência do usuário seja respeitada.

Mais uma vez, é muito bom ver tanto interesse na Alta DPI. Nós certamente temos alguns desafios à nossa frente, mas de muitas maneiras parece que o ecossistema está pronto para esse desafio. Esperamos que este artigo de acompanhamento tenha ajudado a consolidar alguns dos comentários que recebemos sobre o artigo anterior e a explicar algumas das complexidades desse recurso em maior detalhe.

--Ryan Haveson