A principal diferenc¸a do nosso modelo de consciˆencia coletiva em comparac¸˜ao com os demais ´e a possibilidade de se ajustar parˆametros de visualizac¸˜ao por demanda,
4.4 Um a infra -estrutura p a ra re plic a c¸ ˜a o d e m e t ´a fora s 79
Figura 4.1: Componente vis˜ao global.
sob a supervis˜ao do grupo inteiro. E para preservar a consciˆencia seguimos as recomen- dac¸˜oes de Ellis et al [19]: “uma boa interface de grupo deve fornecer uma vis˜ao geral das atividades do grupo e ao mesmo tempo n˜ao provocar a distrac¸˜ao”. Portanto, n˜ao utilizamos o componentevis˜ao de cena para exibir os recursos de reforc¸o `a consciˆencia de forma a n˜ao polu´ı-la com elementos que poder˜ao causar dispers˜ao.
Ao detalharmos o nosso modelo de consciˆencia, identificamos dois problemas: replicac¸˜ao das met ´aforas e dos volumes de visualizac¸˜ao, bem como a sincronizac¸˜ao da renderizac¸˜ao das subjanelas de vis˜ao de cena (scene view) e de vis˜ao global (global view).
4.4.1 Replicac¸˜ao
Para que as informac¸˜oes de consciˆencia, providas pelas met ´aforas 3D e volume de visualizac¸˜ao, sejam compartilhadas entre as aplicac¸˜oes interativas propomos um mo- delo de comunicac¸˜ao entre as aplicac¸˜oes interativas. Este modelo difere do modelo de comunicac¸˜ao entre as aplicac¸˜oes interativas e o servidor de modelagem, que ´e composto por uma arquitetura cliente/servidor em conjunto com um sistema de replicac¸˜ao origi-
nada sempre no servidor de modelagem. A comunicac¸˜ao entre as aplicac¸˜oes interativas, para provimento de consciˆencia coletiva, ´e realizada atrav´es de um sistema de replicac¸˜ao direta, no qual todas as instˆancias da aplicac¸˜ao interativa s˜ao capazes de originar um evento para as demais instˆancias. Pois, ao contr ´ario do modelo de interac¸˜ao distribu´ıda (Cap´ıtulo 3), as informac¸˜oes de consciˆencia ocorrem de participante para participantes, enquanto as informac¸˜oes de interac¸˜ao ocorrem de participante para servidor geom´etrico. A necessidade individual de se ter informac¸˜oes de consciˆencia atualizadas exige que cada ac¸˜ao do usu ´ario seja capturada e replicada aos demais membros sincrona- mente. Desta forma, cada ocorrˆencia de evento que carrega informac¸˜ao de consciˆencia dispara um processo de coleta e replicac¸˜ao da met ´afora e/ou parˆametros de visualizac¸˜ao para as demais instˆancias das aplicac¸˜oes interativas. Por se tratar de operac¸˜oes que ocorrem em alta freq ¨uˆencia e n˜ao ter impacto direto sobre o trabalho corrente, a co- leta dos dados de consciˆencia, especificamente met ´aforas e volume de visualizac¸˜ao, deve ocorrer de forma independente da coleta dos dados de modelagem e sem a intervenc¸˜ao do usu ´ario.
Para assegurar a usabilidade das tele-met ´aforas e tele-vis˜oes, ´e imprescind´ıvel avaliar a latˆencia de consciˆencia. A latˆencia de consciˆencia trd refere-se o tempo gasto para se processar localmente um elemento de suporte `a consciˆencia, replic ´a-lo para as outras instˆancias da aplicac¸˜ao interativa e em seguida renderiz ´a-lo nos seus destinos (Figura 4.2), ou seja,
trd= tlp+ trl+ tr, (4.1)
sendo tlp, trl, e tr, o tempo de processamento local, o tempo de transmiss˜ao e o tempo de renderizac¸˜ao, respectivamente. Comparando-se as equac¸˜oes de latˆencias de consciˆencia com a equac¸˜ao 3.1, nota-se que foi adicionada `a latˆencia das met ´aforas o tempo de transmiss˜ao dos dados dos elementos de suporte `a consciˆencia coletiva.
Para reduzir a latˆencia trd e manter o elevado grau de acoplamento entre os ele- mentos, propomos ainda, como uma tentativa de minimizar a parcela de tempo tr, utili- zar um modo de renderizac¸˜ao mais simples e mais eficiente para os tele-objetos: modo wireframe. Vale ressaltar ainda que a parcela de tempo de processamento local tlp que aparece na equac¸˜ao 4.1 ´e comum `a parcela tlp que aparece na Equac¸˜ao 3.1.
4.4 Um a infra -estrutura p a ra re plic a c¸ ˜a o d e m e t ´a fora s 81 CORBA CORBA Dragger teleDragger Manipulador Obj gráfico Obj geométrico Obj gráfico Apl. interativa Apl. interativa Servidor de modelagem
Figura 4.2: Destaque da latˆencia de consciˆencia
4.4.2 Sincronizac¸˜ao
Para que a OpenGL “desenhe” corretamente a cena nas widgets global e scene
view, uma s´erie de procedimentos deve ser realizada, inclusive indicar o local da renderizac¸˜ao, denominado contexto gr ´afico1. O contexto corrente pode ser determinado atrav´es de uma func¸˜ao daGtkGLArea. No entanto, durante a implementac¸˜ao da aplicac¸˜ao interativa nos deparamos com um problema intrigante relacionado ao contexto e `as m ´ultiplas fontes de eventos. A global view e a scene view tem contextos gr ´aficos pr´oprios, exibindo objetos de naturezas distintas. A primeira ´e reservada para exibir os elementos de consciˆencia coletiva e a segunda, objetos gr ´aficos e espac¸o de manipulac¸˜ao dos objetos gr ´aficos. Os objetos gr ´aficos s˜ao diretamente manipulados na scene view atrav´es dos draggers e cursor-3D, providos pelo MTK. Ao se realizar uma manipulac¸˜ao, informac¸˜oes sobre o dragger s˜ao replicadas em tempo real para todas as instˆancias da aplicac¸˜ao interativa,
inclusive para aquela que replicou os dados, sendo renderizadas na global view, como
1OpenGL n˜ao tem qualquer relac¸˜ao com o sistema de janela, assim o contexto gr ´afico ´e uma estrutura
ilustra a Figura 4.3. Neste instante, o mecanismo de despacho das janelas perde a re- ferˆencia sobre o contexto gr ´afico corrente. Por exemplo, podendo desenhar objetos na scene view com os parˆametros da global view. Isso gera ambig ¨uidades sobre qual janela se capturou as informac¸˜oes, levando a efeitos efeitos visuais incorretos.
global view
global view
scene view scene view
Figura 4.3: Vis˜ao geral da interface gr ´afica e dos componentes scene view e global view A movimentac¸˜ao correta do Cursor-3D depende da obtenc¸˜ao das coordenadas e dimens˜oes da scene view, que o contexto gr ´afico corrente seja o da scene view. Para assegurar isso, projetamos sem ´aforos que impedem que a troca de contexto seja reali-
zada antes do t´ermino da descarga dos comandos OpenGL no contexto corrente. Esta
soluc¸˜ao apresentou-se muito satisfat´oria para o prop´osito do nosso projeto, apesar de conhecermos limitac¸˜oes do X neste sentido. Como trabalho futuro, uma soluc¸˜ao mais interessante, requereria uma ´ardua tarefa de reestruturac¸˜ao do X e GLX para processar adequadamente m ´ultiplas widgets de renderizac¸˜ao e manipulac¸˜ao 3D.