Java passou uns 10 anos sem esse tipo de funcionalidade, porque jmf é uma brincadeira(lerdo e sem recursos).[/quote]
O que me chateia e muito é que esses players não suportam InputStream ou byte array, portanto seria o uso de caminho direto por string ou URL.[/quote]
Para fazer apenas um playback de media você não precisa dos quadros(byte array como você disse). A url é suficiente. Agora para poder processar vídeo precisamos dessa opção, além de um sistema de codecs para podermos fazer também a captura em arquivos. Espero que o pessoal da oracle pense nisso, porque senão javafx vai ser somente um toolkit ria.
Júlio, mas por medida de segurança, poderia ser interessante carregar dessa forma como InputStream, sem protocolo de RMTP nem nada. Ou seja, poderíamos adicionar o vídeo em um banco de dados, estrair a informação e exibi-lo diretamente no player.
Guardar vídeo dentro de um banco está fora de questão grinvon. Isso ia acabar com o desempenho da transmissão. Imagina ter que consultar um banco, ler bits, decodificar, transmitir e posteriormente fazer o caminho inverso. No banco no máximo guardar o caminho do arquivo do vídeo. E imagina um vídeo HD, com milhares de quadros de 1600 por 900 px.
Mas o que eu quis dizer é que javafx hoje não suporta captura nem nenhuma funcionalidade para processar vídeo de maneira adequada. Ele tem bom desempenho, mas para se tornar robusto ainda falta bem coisa.
[quote=mochuara][quote=Jesuino Master]JavaFX veio para ser o que a camada JSE representa hj.
Esperem o J1, ventos da mudança estão chegando
[]'s[/quote]
Hã? JSE? Esta se referindo ao JavaSE? JavaFX vai substituir o JavaSE, não faz o menor sentido essa afirmação. JavaSE é a base do Java , JavaFX é uma tecnologia de apresentação apenas. Esclarece pra gente essa história.[/quote]
Acho que ele quis dizer em substituir o Java SE (Swing/AWT) na camada view no desktop. Da mesma forma em que o JSP/JSF subtitui a utilização direta de classes Java na camada view na web.
[quote=Rafael Afonso][quote=mochuara][quote=Jesuino Master]JavaFX veio para ser o que a camada JSE representa hj.
Esperem o J1, ventos da mudança estão chegando
[]'s[/quote]
Hã? JSE? Esta se referindo ao JavaSE? JavaFX vai substituir o JavaSE, não faz o menor sentido essa afirmação. JavaSE é a base do Java , JavaFX é uma tecnologia de apresentação apenas. Esclarece pra gente essa história.[/quote]
Acho que ele quis dizer em substituir o Java SE (Swing/AWT) na camada view no desktop. Da mesma forma em que o JSP/JSF subtitui a utilização direta de classes Java na camada view na web.[/quote]
Muito provavel que seja utilizado em conjunto com swing. Até porque ele precisa de um container pra rodar.
Container? Você quer dizer rodar JavaFX em cima do Swing? Mas a intenção é remover todas as dependências em relação ao Swing/AWT para que os componentes sejam os mais portaveis possíveis (para Mobile, Web, TV). Embora exista um pacote javafx.ext.swing, a idéia é quie ele seja cada vez menos utilizado.
O que talvez você queira dizer é que no ambiente desktop aí sim o JavaFX utilize o Swing internamente. Mas a impressão que eu tenho é que vão usar Java2D para desenhar os componentes básicos. Alguém pode confirmar ou refutar minha teoria?
[quote=Rafael Afonso][quote=juliocbq]
Muito provavel que seja utilizado em conjunto com swing. Até porque ele precisa de um container pra rodar.
[/quote]
Container? Você quer dizer rodar JavaFX em cima do Swing? Mas a intenção é remover todas as dependências em relação ao Swing/AWT para que os componentes sejam os mais portaveis possíveis (para Mobile, Web, TV). Embora exista um pacote javafx.ext.swing, a idéia é quie ele seja cada vez menos utilizado.
O que talvez você queira dizer é que no ambiente desktop aí sim o JavaFX utilize o Swing internamente. Mas a impressão que eu tenho é que vão usar Java2D para desenhar os componentes básicos. Alguém pode confirmar ou refutar minha teoria?[/quote]
Não, é justamente o contrário. Para escrever uma aplicação desktop usando JavaFx você precisa pintá-lo numa superfície swing. É para isso que serve o widgetsfx. http://widgetfx.org/
Da mesma forma que para escrever uma aplicação opengl, você pinta uma superfície dela em cima de um widget ou componente.
Pode comparar o javafx como um java2d muito mais avançado(Olhando pelo lado gráfico claro).
Outro dia vi aqui no fórum que o swing ia ser descontinuado. E se for!? foi tarde.
No trampo, temos legado em swing e ja estamos substituindo pelo adobe flex na camada view.
Não utilizamos o java fx pois o gerente é mala! :roll:
[quote=mochuara][quote=Jesuino Master]JavaFX veio para ser o que a camada JSE representa hj.
Esperem o J1, ventos da mudança estão chegando
[]'s[/quote]
Hã? JSE? Esta se referindo ao JavaSE? JavaFX vai substituir o JavaSE, não faz o menor sentido essa afirmação. JavaSE é a base do Java , JavaFX é uma tecnologia de apresentação apenas. Esclarece pra gente essa história.[/quote]
Vão acontecer várias mudanças. Uma das coisas que vai acontecer é uso de JavaFX com outras linguagens, como Groovy e Scala.
[quote=marcosalex][quote=juliocbq]
Não, é justamente o contrário. Para escrever uma aplicação desktop usando JavaFx você precisa pintá-lo numa superfície swing. É para isso que serve o widgetsfx. http://widgetfx.org/
Da mesma forma que para escrever uma aplicação opengl, você pinta uma superfície dela em cima de um widget ou componente.
Pode comparar o javafx como um java2d muito mais avançado(Olhando pelo lado gráfico claro).
[/quote]
Eu também achava que fosse o oposto, pra não precisar de usar Swing, que considero um gambiarra em cima de outra gambiarra (awt).
[/quote]
Até não considero gambiarra, você pode utilizar o javafx em qualquer superfície. O swing é java enquanto o awt é nativo. Por isso grande parte dos dispositivos de pintura do java o usam(awt), por questão de desempenho, assim como o swt.
Tentem usar algum componente Java Swing e verão uma mensagem de aviso no console falando que o uso de componentes Java Swing é depreciado.
Nesse JavaOne terá mais detalhes sobre isso!
[/quote]
Do java2d não, e nem do 3d. Essas apis são mapeamentos para opengl ou direct3d. Não há como descartá-las. O prism será baseado nelas.
Então a novidade no JavaOne vai ser um blog post de 2 anos atrás? :lol:
Falando sério, o mínimo que o time do JavaFX deveria anunciar é uma aplicação usando a porra do framework, resolver algum problema real, pra servir como referência, caso de uso. Esse papo de que vai suportar linguagem X , vai rodar em cima de tecnologia Y, é historinha pra boi dormir.
não tem como. Você vai precisar de uma funcionalidade que o html5 não tê provê como uma linguagem de programação real, e ae vai precisar de plugins. Não pensemos que silverlight, javafx são sómente para interfaces ricas ou gráficos. O silverlight hoje roda em cima do directx e vai muito além de fazer playback de áudio e vídeo.
não tem como. Você vai precisar de uma funcionalidade que o html5 não tê provê como uma linguagem de programação real, e ae vai precisar de plugins. Não pensemos que silverlight, javafx são sómente para interfaces ricas ou gráficos. O silverlight hoje roda em cima do directx e vai muito além de fazer playback de áudio e vídeo.[/quote]
Falou tudo. A propósito, já viram sites usando HTML5 pra fazer banners de propaganda? A espearança era acabar com os banners em flash, eheheheheh
