Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Geir Magnusson Jr wrote: This can't be a Java issue - it must be the design-by-committee-for-all-platforms-ever-to-be problem... I would love to see a good sound API in the style of SWT. Call it JavaAudio... ... and implement it on Harmony code, we'd be very receptive to patches and enhancements to ensure the Harmony code works well for you. Regards, Tim Tor-Einar Jarnbjo wrote: Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Stefano Mazzocchi wrote: But look at the bright side: there are probably many other really simple yet useful things that can be done to make java more useful on the desktop and this will be a marketing win for alternative JVMs. That would be to be able to write small java programs which start fast, and which does not have a massive JVM overhead for each. Basically pull the same trick that Microsoft did with their JVM - have the preloaded Java environment being able to spin off new instances fast, giving the end user the impression that this is just another little program. Personally I think it would be great for Linux desktops and utilities. -- Thorbjørn
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Geir Magnusson Jr wrote: This can't be a Java issue - it must be the design-by-committee-for-all-platforms-ever-to-be problem... I would love to see a good sound API in the style of SWT. It's called quicktime for java and has been there for years :-) -- Stefano.
re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Stefano, Are you a Mac user, per chance? Because you sound like one... See below: On 2/17/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: This can't be a Java issue - it must be the design-by-committee-for-all-platforms-ever-to-be problem... I would love to see a good sound API in the style of SWT. It's called quicktime for java and has been there for years :-) -- Stefano. Oh, that contraption? Last time I looked, it relied on Quicktime-for-target-OS being available as well. Try to find a Quicktime for Linux or Quicktime for Solaris I might as well use jffmpeg which interfaces to FFMPEG, which IS available for almost every OS on Earth, unlike Steve's closed little toy. == SourceForge.net: Project Info - JMF wrapper for ffmpeghttp://sourceforge.net/projects/jffmpeg/ http://sourceforge.net/projects/jffmpeg/ Very nice, JMF needs a refresher (an understatement) and it is nice to open source implementations picking up on it (especially since Apple has no idea what they are doing to QuickTime for Java). From the site: This is a Java wrapper for ffmpeg compression library. It exports ffmpeg codecs functions as a JMF (Java Media Framework) codec. You can use this codec from JMStudio and then you'll have a video player able to play mpeg1, h263, mpeg4 (divX), etc. streams. == ^quoted from http://www.walking-productions.com/slop/000609.html FC
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Stefano Mazzocchi schrieb: It's called quicktime for java and has been there for years :-) Sure, Quicktime for Java is not that bad, but unfortunately using heavyweight native GUI widgets, which are difficult to integrate without side effects in a Swing application. If platform dependency is accepted, there are also a lot of e.g. ActiveX-bridges allowing ActiveX-enabled media components (also GUI or video widgets) to be integrated in a Java application. Tor
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/17/06, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote: If platform dependency is accepted, there are also a lot of e.g. ActiveX-bridges allowing ActiveX-enabled media components (also GUI or video widgets) to be integrated in a Java application. Tor Which defeats the whole purpose of cross-platform java in the first place. So why not do it win32 / linux /Gtk then? FC
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia schrieb: Which defeats the whole purpose of cross-platform java in the first place. So why not do it win32 / linux /Gtk then? Because Java as a programming language has other advantages than platform independence. Tor
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/17/06, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote: Fernando Cassia schrieb: Which defeats the whole purpose of cross-platform java in the first place. So why not do it win32 / linux /Gtk then? Because Java as a programming language has other advantages than platform independence. Tor I'm personally not very interested in the programming language advantages. It's the cross-platform independence of java bytecode that makes it special and different from others. Just my $0.02 FC
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: Stefano, Are you a Mac user, per chance? Because you sound like one... Do you have a problem with that? -- Stefano.
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/17/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Fernando Cassia wrote: Stefano, Are you a Mac user, per chance? Because you sound like one... Do you have a problem with that? -- Stefano. No, but I figured because you mentioned Quicktime for Java. Which nobody outside the Mac faithful ever took seriously. Back when the first version was released, a lot of OS/2 folks -myself included- had a lot of hope in the product, and some even asked Apple to do a 100% java version of the codecs and player, that is a TRUE quicktime for java, not a silly wrapper that just interfaces java apps to it and needs the native code player to be available on the target platform, but nobody ever got an official reply (to my knowledge). Over the years, then, the product went nowhere as it was really a solution looking for a problem. FC
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Fernando Cassia [EMAIL PROTECTED] wrote: [snip] You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). Yes, splash screen feature is very important from usability point of you. However the problem itself is not completely clear for me: even early I was able to show splash screen if I wanted. Obviously, Swing stuff takes to much time to be initialized, but it start initialization only when the first reference to Swing is processed, i.e. direct or indirect call requires UIManager to be loaded. Therefore you can easily show splash screen at the begging of the program and continue with loading all other 'heavy-weight' stuff then. Does it make sense? For instance, I used SWT just to show splash screen quickly and then continue with Swing-based UI. Of course, such approach requires VM to be completely initialized anyway (in contrast to Mustang's splashes). I welcome any approaches which makes JVM start up faster :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Anton Avtamonov wrote: On 2/16/06, Fernando Cassia [EMAIL PROTECTED] wrote: [snip] You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). Yes, splash screen feature is very important from usability point of you. However the problem itself is not completely clear for me: even early I was able to show splash screen if I wanted. Obviously, Swing stuff takes to much time to be initialized, but it start initialization only when the first reference to Swing is processed, i.e. direct or indirect call requires UIManager to be loaded. Therefore you can easily show splash screen at the begging of the program and continue with loading all other 'heavy-weight' stuff then. Does it make sense? For instance, I used SWT just to show splash screen quickly and then continue with Swing-based UI. Of course, such approach requires VM to be completely initialized anyway (in contrast to Mustang's splashes). I welcome any approaches which makes JVM start up faster :-) A common technique is for the launcher to open the dialog box (using native platform win man of course), then pass the handle to Java to close after start-up. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: which implements a very interesting trick to speed up java startup performance: save the hotspot information in a repository (at JVM shut down) so that the JIT doesn't have to wait when it starts until it knows what is a hotspot to start compiling it. the performance improvements are not likely to change the perception that java is awefully slow to start up on the desktop, but it's a clever idea. In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this= : http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1 No comment. You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). It's all about PERCEPTION. Java aps are PERCEIVED as slower because the computer appears to freeze until the program's UI is finally showed on the screen (after ALL classes -and even more if it uses Swing- needed to run are loaded- By then, the user is no longer interested in seeing a splash screen, he's already wondering why it took so long See, most Flash content on the web takes an AWFUL LOT of time to download, yet if you ask users, they'll tell you that Flash loads faster than java. The difference? Flash applets can show a message RIGHT AWAY and often display a progress dialog as the rest of the flash cr*p is downloading, telling the user what is going on. In contrast, java applets (and desktop applications as well) freeze the user experience until the applet (or desktop app) has loaded. My point was that it is *trivial* to patch the C code that implements the java JVM loader to add something like that. On an apple computer, since practically 5 years ago, you can double click on a jar file and the icon will start bouncing right away on your dock. My point is: I don't think this is silly, it's a very useful feature, but it's *lame* that it took them almost 10 years to realize they needed it! But look at the bright side: there are probably many other really simple yet useful things that can be done to make java more useful on the desktop and this will be a marketing win for alternative JVMs. We need to find the tab-browsing-equivalent of a JVM ;-) -- Stefano.
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We need to find the tab-browsing-equivalent of a JVM ;-) It's simple, Google should make one of their apps a cross-platform, Swing based java one. Google, unlike Sun, will then have the marketing power to convince vendors to preload a java VM on their systems. Issue solved. Microsoft can get away with the huge bloated .Net runtime just because they ship it with newer Windows versions. Otherwise nobody would donwload it I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. H*ck, there's even a pure-java mpeg4 implementation Open source streaming media in Java™ MediaFrame is an Open Source http://mediaframe.org/#opensource streaming media platform in Java™ which provides a fast, easy to implement and extremely small applet that enables over 97% (AdShadowhttp://adshadow.com/2002-03) of web users to view your audio/video content without having to rely on external player applications or bulky plug-ins. MediaFrame does not require special servers, software or programming knowledge (feature list http://mediaframe.org/#features). MediaFrame is based on open standards and is compatible with Mpeg (Mpeg-1 Mpeg-4), the industry standard in video compression. This enables users to create MediaFrame ready content in any number of applications, from Adobe AfterEffects to Media Cleaner. MediaFrame is feature complete for Mpeg-1 and in Beta release for Mpeg-4. Both the Mpeg-1 Mpeg-4 versions of MediaFrame are availble for download now, along with source code, documentation and sample video.. MediaFrame is* dual license software*. Under this model, users may choose to use MediaFrame under the free software/open source GNU General Public License (commonly known as the GPL) or under a commercial license. Google Plans to add video to Google Talk http://australianit.news.com.au/articles/0,7204,16554205%5E24170%5E%5Enbv%5E24169,00.html Btw: Pretty impressive things can be done with JDIC, things that make Java desktop apps look and feel like native code: minimize to windows systray (o Gnome panel on Linux), call the system's default web browser, and more. See: https://jdic.dev.java.net/ One killer example of today=B4s desktop java technology is Azureus, the bittorrent client (http://azureus.sourceforge.net). Just my $0.02 FC -- Hay dos caminos claros para mí: la creatividad o el ridículo Adolfo Castelo (1940-2004)
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
This can't be a Java issue - it must be the design-by-committee-for-all-platforms-ever-to-be problem... I would love to see a good sound API in the style of SWT. Call it JavaAudio... Tor-Einar Jarnbjo wrote: Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor
I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: which implements a very interesting trick to speed up java startup performance: save the hotspot information in a repository (at JVM shut down) so that the JIT doesn't have to wait when it starts until it knows what is a hotspot to start compiling it. the performance improvements are not likely to change the perception that java is awefully slow to start up on the desktop, but it's a clever idea. In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this= : http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1 No comment. You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). It's all about PERCEPTION. Java aps are PERCEIVED as slower because the computer appears to freeze until the program's UI is finally showed on the screen (after ALL classes -and even more if it uses Swing- needed to run are loaded- By then, the user is no longer interested in seeing a splash screen, he's already wondering why it took so long See, most Flash content on the web takes an AWFUL LOT of time to download, yet if you ask users, they'll tell you that Flash loads faster than java. The difference? Flash applets can show a message RIGHT AWAY and often display a progress dialog as the rest of the flash cr*p is downloading, telling the user what is going on. In contrast, java applets (and desktop applications as well) freeze the user experience until the applet (or desktop app) has loaded. I wonder why no one has tought about having java auto-load at startup and having a single instance of the Java VM running all the time, and then pass control of the first loaded java application to it (as Mozilla or Firefox pre-loads itself at boot time when the quick launch feature is enabled). FC
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia fcassia at gmail.com writes: I wonder why no one has tought about having java auto-load at startup and having a single instance of the Java VM running all the time, and then pass control of the first loaded java application to it (as Mozilla or Firefox pre-loads itself at boot time when the quick launch feature is enabled). People have thought about it, and done it to death, in so far as it can be done. It turns out to not work that great in practice for a lot of reasons: the class libraries are not designed for that, the VMs are not designed for that, the security model is not designed for that at all, etc. In order to do it somewhat sensibly, you need isolates, and isolates are having their winter sleep at this point, judging by the JSR mailing list activity (none in past two months). Yay JCP! :) cheers, dalibor topic
