[Rio-pm] Res: Perl melhor que C para OpenGL (?!)

Terça Abril 17 20:28:10 PDT 2007

Hummm...

Pelo pouco que conheço de opengl, eu sempre entendi que servia para
processamento de imagens diretamente no hardware local... agora se há
como salvar estas imagens para transferencia, ótimo! Melhora as formas
de explorar ;)

http://www.opengl.org/resources/faq/technical/miscellaneous.htm

24.050 How can I save my OpenGL rendering as an image file, such as
GIF, TIF, JPG, BMP, etc.? How can I read these image files and use
them as texture maps?

    To save a rendering, the easiest method is to use any of a number
of image utilities that let you capture the screen or window, and save
it is a file.

    To accomplish this programmatically, you read your image with
glReadPixels(), and use the image data as input to a routine that
creates image files.

    Similarly, to read an image file and use it as a texture map, you
need a routine that will read the image file. Then send the texture
data to OpenGL with glTexImage2D().

    OpenGL will not read or write image files for you. To read or
write image files, you can either write your own code, include code
that someone else has written, or call into an image file library. The
following links contain information on all three strategies.

    This file format information covers a variety of different file formats.

    The Independent JPEG Group has a free library for reading and
writing JPEG files.

    You can save your rendering as a JPEG image file, plus load JPEG
and BMP files directly into OpenGL texture objects, using the C++
mkOpenGLJPEGImage class.

    Source code for reading TGA files can be found here.

    The gd library lets you create JPG and PNG files from within your program.

    Imlib (search the "Download" section) is a wrapper library that
allows a program to write out JPEG, GIF, PNG, and TIFF files.

    An image loader library in Delphi can be found here.

Em 17/04/07, Ricardo Filipo<ricardo_filipo em yahoo.com.br> escreveu:
>
> Oi, Marco.
> A coisa pode estar criando imagens em tempo real, como gráficos, ícones ou
> vídeos, para apresentação na web. :)
>
> ----- Mensagem original ----
> De: Marco A P D'Andrade <mdacwb em gmail.com>
> Para: Perl Mongers Rio de Janeiro <rio-pm em pm.org>
> Enviadas: Terça-feira, 17 de Abril de 2007 18:15:11
> Assunto: Re: [Rio-pm] Perl melhor que C para OpenGL (?!)
>
>
> Breno,
>
> Achei muito interessante suas informações, mas fiquei confuso com uma coisa
> ...
>
> Você entendeu a vantagem de usar OpenGL com mod_perl ?? Me parece um
> tanto contrastante ...
>
> Sds,
> Marco Antonio
>
> Em 16/04/07, breno<breno em rio.pm.org> escreveu:
> >
> >
> > Desenvolvedores de soluções Desktop costumam partir do princípio que
> > linguagens compiladas funcionam sempre mais rápido que as interpretadas
> > (como Perl).Ainda que muitos desenvolvedores de serviços online já estejam
> > acostumados com mecanismos que carregam interpretadores como mod_perl e
> > ISAPI e cujo desempenho se aproxima bastante daquelas em C/C++, são poucos
> > os desenvolvedores 3D que pensam em Perl quando o objetivo é performance.
> > Bom, eles deveriam!
> >
> > GPUs (Graphics Processing Units) são microprocessadores especializados em
> > processamento de gráficos disponíveis em todas as placas de vídeo
> modernas,
> > e estão a cada dia tirando a carga das CPUs para o tratamento de números.
> O
> > processamento moderno de GPGPU (General Purpose GPUs) se aproxima de
> > programas em C e carrega grandes vetores de dados dentro da GPU, onde o
> > processamento acontece independentemente da CPU. Como resultado, a
> > contribuição de programas atados à CPU diminui, e a diferença entre Perl e
> C
> > se tornam insignificantes em termo de performance GPU.
> >
> > A mais nova versão do módulo POGL (Perl OpenGL), disponível em
> > http://graphcomp.com/opengl/ e diretamente via CPAN, adicionou suporte ao
> > GPGPU. O autor colocou ainda uma série de benchmarks entre C e Perl,
> > demonstrando não haver qualquer diferença estatística de performance entre
> > implementações em C e em Perl, e apresentando inclusive casos em que a
> > performance em Perl é melhor do que em C para operações OpenGL!
> >
> > De um modo geral, C foi melhor que Perl em operações Vertex/Fragment
> Shader,
> > enquanto Perl foi melhor em operações de Objetos Frame Buffer. Essa
> > similaridade é explicada por diversos fatores, dentre eles a alta
> quantidade
> > de operações realizadas pela GPU; o fato do POGL ser um módulo C
> compilado;
> > e que operações não-GPU são mínimas. Ainda assim, esse é de fato o
> ambiente
> > típico de operações de processamento e renderização de imagens. E é aí que
> > entram as vantagens do Perl, seja na portabilidade, facilidade e agilidade
> > de desenvolvimento, diversos módulos de imagens para carregar texturas em
> > vetores de dados GPGPU, ser essencialmente mais rápido do que Java (em
> > especial sob mod_perl/ISAPI), ou pelo simples fato de não haver suporte a
> > FBO (Frame Buffer Objects) em Java, Python ou Ruby até a data de hoje. E
> os
> > resultados mais favoráveis ao Perl foram obtidos onde? No Windows Vista!
> >
> > Com Perl, desenvolvedores OpenGL/GPU de Desktops podem prototipar seus
> > códigos rapidamente em Perl e depois portar (caso necessário) para C/C++
> > mais tarde. É fácil perceber também as vantagens em escrever o código em
> uma
> > janela e executar na outra sem qualquer IDE ou compilação, permitindo
> > experimentações em tempo real com novos algoritmos, modelos e efeitos
> > especiais.
> >
> > --
> > Notícia adaptada, original por Shlomi Fish, Bob Free, Mike Friedman e
> Brian
> > D Foy em www.perl.com
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> >
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
> __________________________________________________
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger.yahoo.com/
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>