Para configurar os speakers de forma que os conectores frontais possam ser usados juntos com os trazeiros (permitindo a você ligar suas caixas / receiver OU usar o fone de ouvido no painel frontal, podendo inclusive ligar dois receivers um em cada lado (!), abra o programa de configuração do Realtek HD Audio, clique no link da direita (opções avançadas) e marque o primeiro radio button e clique OK. Agora os conectores frontais não aparecem mais nas abas do programa (2nd Speaker) e você só precisa selecionar a aba Speaker e clicar no botão para torná-lo a saída preferencial. Para testar basta colocar uma música para tocar. Se tocar no fone de ouvido e nas caixas deu certo!

Com um pouco de pesquisa achei um tutorial sobre como editar o registro do Windows e adicionar meu próprio comando “Abrir com Notepad++”. Desta forma funcionou, então vamos divulgar o passo-a-passo porque pode ser útil para outros programas também.O procedimento é muito simples e pode ser executado em qualquer versão do Windows:

1. Abra o editor de registro do Windows (regedit.exe)
2. Navegue para a chave HKEY_CLASSES_ROOT/*/shell
3. Clique com o botão direito em shell e selecione Novo => Chave.
4. Escreva o nome do novo comando como nome da chave (ex: Abrir com Notepad++
5. Crie uma sub-chave command.
6. Do lado direito, edite o valor da chave para o comando que você quer executar. O nome do arquivo será o primeiro argumento do comando então no caso do Notepad++ em um Windows de 64-bits serie “C:\program files (x86)\notepad++\notepad++.exe %1″
7. Clique OK e a alteração já terá efeito imediatamente.

O link mencionado anteriormente traz screenshots de como realizar este procedimento.

Neste artigo vamos falar um pouco sobre GPGPU e minhas primeiras impressões sobre a OpenCL, uma nova API criada para ser o padrão para computação distribuída.

General Programming on the GPU

Já faz algum tempo (pelo menos nos últimos 7 anos desde o lançamento da série GeForce3 pela NVIDIA) que a indústria de jogos vem escrevendo pequenos programinhas (shaders) que permitiam maior controle por parte dos desenvolvedores sobre o hardware gráfico, permitindo que eles criassem efeitos inéditos como modelos de iluminação avançados, mapeamento de sombras e outras técnicas que tornassem os novos jogos cada vez mais realistas, indo além dos modelos de texturização e iluminação do então chamado pipeline de funções fixas, que são as funcionalidades padrão do OpenGL e Direct3D.

Os primeiros shaders (da época do Direct3D8 e Direct3D8.1 eram escritos em um dialeto de assembly com instruções como as seguintes:

; Scale by fog parameters :
; c5.x = fog start
; c5.y = fog end
; c5.z = 1/range
; c5.w = fog max
dp4 r2, v0, c2 ; r2 = distance to camera
sge r3, c0, c0 ; r3 = 1
add r2, r2, -c5.x           ; camera space depth (z) - fog start
mad r3.x, -r2.x, c5.z, r3.x ; 1.0 - (z - fog start) * 1/range
                            ; because fog=1.0 means no fog, and
                            ; fog=0.0 means full fog
max oFog.x, c5.w, r3.x      ; clamp the fog with our custom max value

Anos depois surgiram linguagens como a GLSL (OpenGL Shading Language, Khronos), HLSL (High Level Shading Language, Microsoft) e Cg (C for Graphics, NVIDIA). Estas linguagens se pareciam muito com a linguagem C, porém com extensões apropriadas para GPUs, como tipos vetoriais (float2, float3, float4 …) e matriciais (float4x4, float4x3) com um abrangente acervo de funções para manipular estes tipos com o mínimo de overhead possível.

Com a adoção de tais linguagens e hardware preparado para usar PCI Express (PCIe),  um barramento mais veloz que os antigos AGP e PCI, alguns pesquisadores da indústria e acadêmicos começaram a se interessar pelo uso das GPUs como uma unidade auxiliar de processamento, principalmente em cálculos cientificos e motores de física para jogos, fazendo com que os shaders escrevessem o resultado de seu processamento em texturas que depois eram recuperadas pela aplicação. O uso destes shaders ficou conhecido como GPGPU, porque utiliza os porcessadores gráficos (GPUs) para programação de propósito geral.

De uns anos para cá as GPUs evoluiram muito tanto vertical quanto horizontalmente. A cada nova geração elas ficam mais velozes e trazem mais e mais stream processors (nome dado aos núcleos, cores, que executam shaders na GPU). Por exemplo, a ATI Radeon HD 5970 (placa top de linha da série Radeon HD 5000) vem equipada com 3200 stream processors executando a um clock de 725MHz e 2GB de memória a um clock de 1GHz. Todo este aparato é capaz de processar 4.64TFLOPS. Em comparação, segundo o site MaxxPF, Core 2 Quads chegam em torno de 7,5GFLOPS e Core i7s ficam em torno dos 14GFLOPS.  É importante lembrar que a correlação destes dados pode induzir conclusões erradas: uma CPU tem uma arquitetura muito mais rica e abrangente que uma GPU, que é um hardware dedicado a cálculos e gráficos.

OpenCL

Open Computing Language é uma nova linguagem de programação de GPUs proposta pela Apple em 2008 e desenvolvida pelo Khronos Group em parceria com empresas como Intel, AMD, NVIDIA e IBM para criar uma arquitetura padrão para computação em sistemas heterogêneos. Por sistema heterogêneo podemos entender sistemas que utilizam processamento distribuído entre vários dispositivos em um mesmo computador, como CPU, GPU, chips aceleradores e outros. A proposta da OpenCL é prover uma especificação que, quando implementada, permita acessar os diversos dispositivos da mesma forma, podendo-se trocar o dispositivo e executar os mesmos kernels (programas) em outros dispositivos. Na prática, isto significa que o mesmo kernel pode ser compilado e executado em uma GPU conectada a um PC, no MacOS X Snow Leopard ou no processador Cell do PlayStation 3.

É muito comum encontrar na internet documentos que comparem OpenCL à tecnologia CUDA da NVIDIA. Isto acontece porque, de uma certa forma, a OpenCL é uma versão royalty-free da CUDA, planejada para ser implementada pelos diversos fabricantes de chips e processadores. Atualmente tanto NVIDIA como ATI já lançaram drivers e SDKs com suporte a OpenCL 1.0. Para executar OpenCL na GPU é necessário uma placa de vídeo GeForce 8 ou superior ou ATI Radeon HD das séries 4000 e 5000.

A especificação da OpenCL determina uma API que permite a comunicação entre a aplicação e o dispositivo OpenCL (Host API) e uma linguagem que estende o padrão C89 para a escrita dos kernels.

A Host API tem uma nomenclatura e paradigma de programação muito parecido com a OpenGL, onde a comunicação entre aplicação e API é feita com funções simples e os recursos alocados dinamicamente são tratados como IDs numéricos, o que facilita muito a criação de pontes entre a API em C e outras linguagens de programação como Python e C#.

Outra característica interessante é a presença de callbacks na API, permitindo que algumas tarefas demoradas (como compilar um kernel, executá-lo ou ler o valor de um buffer) podem ser executadas sem bloquear a aplicação.

Aplicativo de Exemplo

Faça download do aplicativo de exemplo

Escrevi um pequeno programa de exemplo para estudar o funcionamento da OpenCL e suas vantagens em relação ao código executado somente na CPU. Neste exemplo, crio dois vetores, um de entrada e um de saída, preenche o primeiro com números aleatórios e executa um algoritmo trivial a escolha do usuário (calcular fatorial ou determinar se o número é primo). Os dois algoritmos estão implementados tanto em C quanto em OpenCL e o programa imprime o tempo gasto para alocar memória, fazer cálculos usando a CPU, criar contexto OpenCL, compilar o kernel selecionado e executá-lo. É importante notar que, tirando o passo de executar o algoritmo, todos os outros precisam ser feitos apenas uma vez por execução, o que significa que um sistema real que use OpenCL pode compilar seus kernels ao iniciar e depois apenas escrever nos buffers e executar os kernels quando necessário.

Observações

1. Neste exemplo estou usando a implementação da OpenCL que vem no ATI Stream SDK 2.0 e uma placa de vídeo ATI Radeon HD 5750. Não testei este software em outras máquinas ainda!
2. Como existem várias implementações de OpenCL (NVIDIA, ATI….) coloquei o caminho para os arquivos .h (include) e .lib (Library) fora do arquivo de projeto, ou seja, você precisará incluir estes caminhos para recompilar o programa!

Resultados dos testes

A diferença de performance entre executar um algoritmo dentro da aplicação ou na GPU é altamente dependente do hardware que executa a aplicação, mas na minha máquina de teste os algoritmos rodaram com uma economia de tempo entre 50% e 70%, chegando algumas vezes a 85%. Por serem algoritmos triviais fica difícil saber se estes valores podem ser reproduzidos em uma aplicação completa.

Conclusão

Apesar de ser um paradigma diferente de programação, as técnicas de GPGPU vem sendo aprimoradas a cada dia. O foco da GPGPU não é trocar a CPU por uma placa de vídeo, mas sim abrir novos caminhos para aumentar a escalabilidade do processamento em desktop e estações de trabalho. Uma das otimizações do Windows 7 em relação ao Vista é o uso mais intenso de pixel shaders para criar os efeitos especiais do Windows Aero.

Ontem pesquisei um guia para melhorar a performance do navegador. Todas as mudanças propostas no artigo no final deste post são feitas através de parâmetros do navegador acessados pelo comando about:config e muitos dos parâmetros disponíveis exigem algum grau de conhecimento técnico.

Talvez nem todas as modificações propostas façam muita diferença para você, mas certamente os primeiros ajustes (pipeline e aumento do limite de conexões) vão deixar seu Firefox bem mais rápido!

Segue o link: A Handful of Firefox Tweaks That Will Double Your Browser Speed

Neste artigo iremos descrever problemas encontrados por desenvolvedores para adequar seus sites ao navegador Web do DOSVOX, o Webvox, e principalmente como implementar uma rotina de autenticação de usuários (login) que funcione neste sistema.

Projetando sites para funcionar no Webvox

Abaixo descrevo algumas  técnicas que desenvolvi durante alguns meses de projeto para criar um site navegável pelo DOSVOX.

Escolhendo uma DTD adequada

Apesar de não aplicar nenhum tratamento especial à maioria das marcações HTML,  o Webvox tem consciência de que deve seguir uma DTD (definição de tipo de documento) quando uma é informada no início da página. Se seu site usar XHTML, fique de olho no Apêndice C.8. Fragment Identifiers da especificação do XHTML 1.0. que recomenda utilizar os atributos name e id com o mesmo valor de forma a manter compatibilidade com navegadores antigos.

Cada louco com sua mania: HTTP  na visão do Webvox

Um detalhe importante do funcionamento do Webvox é como ele trata os cabeçalhos HTTP, principalmente os descritos abaixo:

• Content-Type: Você pode especificar o charset que quiser, mas o Webvox só trabalha com ISO-8859-1. Em outras palavras, se você usa uma tecnologia moderna como ASP.NET, Java e outras deve ter notado que os caracteres acentuados são lidos de forma errada. Isso acontece porque o Webvox não entende nada de Unicode e tentará interpretar suas páginas como ISO-8859-1, mesmo que você indique UTF-8 no Content-Type. Este problema não acontece com texto codificado usando as entidades do HTML/XHTML (´ , ç entre outras) porque neste caso o código enviado pelo servidor só contem caracteres reconhecidos na codificação ISO-8859-1.
• Response.Redirect(url): a clássica instrução do ASP, herdada pelo ASP.NET e presente em 10 em cada 10 tecnologias Web, equivalente a retornar um status HTTP 302 e uma nova URL que deve ser chamada pelo navegador. O Webvox, como qualquer outro navegador Web, interpreta tal instrução, porém do jeito “dele”. Veja só: o WebServer retornou um código 302 (recurso foi movido permanentemente), então ele desconsidera qualquer cookie que tenha sido informado na resposta e reenvia a solicitação para a nova URL do recurso. Assim, o cookie é perdido!

Por que não loga?

Uma reclamação constante de usuários de DOSVOX é não conseguir passar da tela de login em sites como Gmail, Orkut, Facebook e outros. O comportamento é parecido com o que acontece se você desligar os cookies de um navegador tradicional: após enviar o formulário o sistema volta na tela de login, sem mensagem de erro ou aviso. Daí vem a crença de que o DOSVOX não suporta cookies. Na verdade, ele suporta. O problema destes sites que citei e de muitos outros está entre o teclado e a cadeira, e no velho hábito que nós desenvolvedores temos de achar que uma tela de login é “somente mais uma tela de login”.

Lembram quando  falei do Response.Redirect() e que o DOSVOX entende que se o recurso foi movido ele deve correr atrás da URL indicada pelo servidor? Pos bem,  quando recebe os cabeçalhos de redirecionamento o DOSVOX ignora qualquer outra informação que venha depois no cabeçlalho HTTP, inclusive os cookies!

Pois bem, a solução pode ser algo tão simples quanto trocar o Response.Redirect() por uma trecho de HTML com uma mensagem de sucesso edisponibilizar um link para a área restrita do site. Só isso

Campos de formulário

Por fim, temos dois campos de formulário problemáticos, pois se comportam de maneira atípica no Webvox:

• Checkboxes: por padrão, uma checkbox tem o valor “on” se o atributo value não for especificado. Quando enviamos o formulário, é normal que o navegador envie o valor da checkbox (“on” ou o que foi especificado pelo desenvolvedor) se a checkbox foi marcada. Do contrário, não envia nada. O Webvox tem novamente uma interpretação singular, e envia “off” quando a checkbox não está marcada, “on” quando marcada e sem valor no atributo value, e “on,valor” se informarmos algum valor para a checkbox.
• Textarea: Uma coisa chata em relação às caixas de texto com múltiplas linhas no Webvox é o número de colunas. O  navegador obedece à risca o valor do atributo cols, porém não muda de linha quando chega no limite, nem emite um bipe para avisar ao usuário que chegou no limite daquela linha. Não fiz muitos testes com textyareas, mas este aspecto me irrita muito quando estou homologando meus sites pelo DOSVOX!

Conclusão

É incrível acreditar como alguns poucos detalhes, que normalmente passam despercebidos, podem fazer a diferença entre um site funcionar ou não no Webvox. Se você tiver dúvidas, ou souber de mais alguma particularidade do Webvox, comente este post! Acredite, pode ser algo que só você conheça e compartilhar este conhecimento pode contribuir para que todos os usuários, deficientes ou não, tenham acesso à Informação.

Shigeu Miyamoto (Nintendo)

Shigeru Miyamoto, pai do Mario Bros.

Considerado por muitos o Walt Disney dos videogames, Miyamoto nasceu em 1952 em Kyoto e começou a trabalhar na Nintendo em 1977 como artista em um jogo para arcade chamado Radar Scope.  Dentre os games criados por ele, os mais famosos foram as séries Mario,  Donkey Kong, Zelda e Pokemon. A primeira aparição do personagem Mario foi em 1981 no arcade Donkey Kong, no qual o personagem aparecia com o nome Jumpman em sua versão japonesa. Durante a localização de Donkey Kong para a América o nome foi mudado para Mario em homenagem a Mario Segali, que bateu as portas da Nintendo para cobrar o aluguel atrasado.

Tenho que confessar que nunca tive um videogame da Nintendo, mas realmente o cara é bom e criou vários jogos que serão lembrados por muitas gerações

Yu Suzuki (Sega / AM2)

Yu Suzuki, principal produtor do estúdio AM2 da Sega

Rival de Miyamoto, Yu Suzuki nasceu em 1958 e se formou como programador no início dos anos 80. Começou a trabalhar para a Sega em 1983 no estúdio AM2 em um jogo de Boxe para os arcades. Também idealizou grandes clássicos, cada novo jogo trazendo inovações para a indústria como os clássicos Hang-On, Space Harrier, Out Run, Virtua Racing e Virtua Fighter.

Para criar Hang-On, Suzuki passou horas aprendendo como pilotar motos e muitas outras horas testando o gabinete protótipo do jogo, que era composto apenas de uma moto estacionada queo  jogador deveria deitar para os lados. Out Run foi outro jogo inovador, com uma trilha sonora inesquecível e vários caminhos que levavam a uma das 5 fases finais do jogo. Virtua Racing era inicialmente apenas uma prova de conceito para que a equipe da AM2 ganhasse mais experiência com a nova placa Model-1, mas os resultados foram tão bons que a AM2 decidiu terminar o jogo e lança-lo em outubro de 1992. Em 1993 Suzuki lançou Virtua Fighter, primeiro jogo de luta 3D a fazer sucesso nos arcades.

Atualmente Suzuki trabalha no departamento de pesquisas da Sega em um novo estúdio chamado AM Plus.

John Carmack (Id Software)

John Carmack, co-fundador da Id Software

Nascido em 20 de agosto de 1970, John Carmack era um moleque problemático que aos 14 anos foi preso por invadir uma escola para roubar alguns computadores Apple II. Após cursar dois semestres na University of Missouri–Kansas City, Carmack começou a faer freelances como programador para uma empresa chamada Softdisk, onde conheceu outros programadores com os quais fundaria anos depois a Id Software.

Dos primeiros títulos da Id Software os mais importantes certamente foram as séries Wolfstein, DOOM e Quake, que deixaram Carmack conhecido por desenvolver e adaptar técnicas avançadas de computação gráfica em jogos de computador. Suas engines 3D foram usadas posteriormente por várias empresas e desenvolvedores independentes, o que deu a Carmack e sua empresa uma boa reputação na comunidade do software livre.

Uma filosofia interessante de Carmack adotada por sua antiga parceira Apogee e por outras empresas como a Blizzard Entertyainment é a forma como ele gosta de trabalhar com prazos. Quando perguntado quando seu novo jogo será lançado não se espante se ele responder “quando estiverem prontos”.

Durante suas férias em 2005, Carmack estava jogando no celular de sua esposa e concluiu que os jogos para celular disponíveis até então eram muito ruins. Ao voltar de férias John anunciou o desenvolvimento de Doom RPG.

David Jaffe (Lionhead Studios / Microsoft)

Nascido em 1973, David desenvolve jogos profissionalmente desde os tempos do SuperNES (Mickey Mania), mas ficou consagrado mesmo com as séries Twisted Metal (1995-2008) e mais recentemente God of War.

Conclusão

Este artigo é curto demais para expressar toda a criatividade que move as engrenagens da maior indústria de entretenimento do mundo (já foi tempo do cinema), mas com algumas pesquisas na Wikipedia pude relembrar alguns fatos e descobrir outros que mostram que ser criativo e inovador exige mais do que simplesmente vontade: é preciso experiência, conhecimento técnico e acima de tudo dedicação.  Tente trazer as experiências destes gênios para seu dia-a-dia e encontrar maneiras de surpreender seus clientes e parceiros com naturalidade.

Feliz dia do designer a todos aqueles que usam a criatividade, seja em programas de manipulação de imagens, seja criando modelos e animações em 3D ou escrevendo códigos de qualidade para seu próximo produto.

Porém, como nem tudo na vida é perfeito, é claro que sempre encontramos problemas pela frente….

O problema do Flex Devorador de CPU

O problema acontecia na tela principal do “programinha”, que com o passar do tempo aumentava o volume de processamento até o navegador alocar entre 90% e 100% do tempo de CPU da máquina. Depois de algumas pesquisas em fóruns e blogs descobri que o mecanismo de binding  do Flex é inacreditavelmente lento, mas mesmo reduzindo a quantidade de bindings não resolvia o problema, no máximo amenizava sensivelmente.

Por incrível que pareça descobri hoje que o problema não era o Flex, nem as músicas que eu carregava via streaming, nem o data binding do MXML, nem a classe que eu implementei para fazer background em degradê, nem o frameRate da aplicação e muito menos o Garbage Collector do Flash Player! Era tudo culpa de um componente safado que eu escrevi para representar uma barra de progresso no estilo do site porque a que vem com o Flex é muito feia e estava sem paciência de customiza-la!

Mágias à parte, vamos à lição aprendida:

Criando um componente em Flex

Se no Flash criamos classes derivadas de flash.display.MovieClip para criar MovieClips baseados em classes, componentes Flex puros devem herdar de UIComponent, a classe pai de todos os outros componentes Flex (VBox, LinkButton. Herdar de UIComponent nos dá um componente vazio, inanimado, que não desenha nada e não dispara eventos. Bom, vamos colocar alguma coisa dentro de nosso componente!


<?xml version="1.0" encoding="utf-8"?>
<mx:UIComponent xmlns:mx="http://www.adobe.com/2006/mxml"
>
<mx:Script>
<![CDATA[
[Bindable]
public var maximum:Number;
[Bindable]
public var value:Number;
public function setProgress(v:Number, max:Number):void
{
var oldPerc:Number = int(100 * ( (1.0 * this.value) / this.maximum));
var newPerc:Number = int(100 * ((1.0 * v) / max));
maximum = max;
if(oldPerc != newPerc)
{
value = v;
this.invalidateDisplayList();
}
}
override protected function updateDisplayList(uw:Number, uh:Number):void
{
graphics.beginFill(0x333333);
graphics.drawRect(0, 0, uw, uh);
graphics.endFill();
if(this.maximum > 0 && this.value > 0)
{
graphics.beginFill(0xAAAAAA);
graphics.drawRect(0, 0, uw * this.value / this.maximum, uh);
graphics.endFill();
}

}
]]>
</mx:Script>
</mx:UIComponent>

Observe as linhas em vermelho. O método invalidateDisplayList() informa ao Flash Player que aquele componente precisa ser redesenhado. Isso é uma prática comum na programação de aplicativos Windows (os antigos costumavam chamar esta técnica de Dirty Rectangles). Já o método updateDisplayList serve para informarmos ao Flash Player como desenhar nosso componente. É nele que redimensionamos componentes internos (no caso de nosso componente ser um container) e podemos usar a Drawing API para desenhar a interface de nosso componente (no meu caso uma barra de progresso flat). Este evento não é chamado a cada frame do filme, por isso precisamos chamar invalidateDisplayList a cada vez que quisermos atualizar a exibição de nosso componente. Parece uma boa idéia chamar invalidateDisplayList a cada frame e a informação estará sempre atualizada, certo? Errado!

A solução

A chamada ao método invalidateDisplayList dentro do evento enterFrame do componente causa um aumento exponencial no processamento do Flash Player, até que o processamento chega a 100% e o frameRate fica extremamente lento! Com este simples descuido seu aplicativo revolucionário pode ficar conhecido como um comilão de CPU!

No caso da minha barra de progresso, eu alterei o método setValue para cuidar desta nobre tarefa de redesenhar o componente, e ele só faz isso quando o percentual (armazenado na variável newPerc) é alterado. Esta é uma forma grosseira de fazer as coisas, mas funciona para o que eu preciso e passa a idéia de que não devemos redesenhar loucamente na tela, mesmo que seja apenas em um pequeno retângulo….

Ufa! Depois de remexer todo o código e muita pesquisa, finalmente posso dormir em paz sem me preocupar com o Flex Devorador de CPU

Porém, assim como acontecem com programadores JavaScript e estilizadores CSS, programadores ActionScript também precisam ficar atentos aos recursos disponíveis para suas aplicações, principalmente quando desenvolvendo componentes que rodem em vários runtimes (Flash 9, Flash 10, AIR). Podemos detectar facilmente a versão do Flash Player e os recursos disponíveis na plataforma usando a classe Capabilities, como no exemplo abaixo, onde recupero a versão do Flash Player para distinguir entre a versão 9 e a 10:

private function getMajorVersion():uint
{
var xp:RegExp = new RegExp("^\\w+ (\\d+)");
var match:Array = xp.exec(Capabilities.version);
return uint(match[1]);
}

Com um pouco de criatividade criei o seguinte método que resolve o problema acima com menos linhas de código:

private string CleanupHTML(string html)
{

html = Regex.Replace(html, @"(<\w+>|<\/\w+>)", "\n");
XmlDocument doc = new XmlDocument();
doc.LoadXml(@"<?xml version=""1.0""?>
<!DOCTYPE html SYSTEM """ + HttpContext.Current.Server.MapPath("~/XML/DTD/xhtml1-transitional-1.dtd") + @""">
<html>
<head>
<title>simple document</title>
</head>
<body>
" + html + "</body></html>");
return doc.DocumentElement.LastChild.InnerText;

}

A primeira instrução remove as tags HTML e coloca uma quebra de linha para evitar que as palavras se juntem. Exemplo: <p>Hello</p><p>World</p>. O restante do método carrega a string dentor de um documento XHTML (o DOCTYPE é obrigatório para que o XmlDocument entenda as entidades &aacute; &agrave; etc) e recupera o InnerText do Body. Desta forma, substituimos todas as entidades XHTML muito esforço

ATUALIZADO EM 15/10/2009

A solução que eu havia postado anteriormente deu problema porque o servidor do W3C  controla os acessos às DTDs para evitar abuso (dispara erros HTTP 503 se a DTD for acessada repetidamente pelo mesmo IP) de forma que o método parou de funcionar. Sabendo que o dia hoje seria corrido (vai ser ainda!) e que não tenho muito tempo para pesquisar outros métodos, customizei a minha solução usando uma DTD montada localmente, que não acessa nenhum arquivo externo, o que é bom pois vários data centers costumam limitar as portas e protocolos que um Application Server pode usar para se comunicar com o mundo exterior.

O código acima já está corrigido.

Baixa a DTD modificada.

Problema

Could not load type ‘System.Web.Mvc.ViewPage<…>

Evidência / Exemplo

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/MeuPerfil.Master"
Inherits="System.Web.Mvc.ViewPage" %>


Solução

Substituir a tag <pages> no web.config pela tag abaixo. Mantenha qualquer atributo que você eventualmente tenha adicionado.
<pages
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">