Supporting 64bit is not very important when most of your code is in Java. But Teppefall does have around 300kb of C++ that needs to be ported. And the process is something like this.

• Install crazy big Windows SDK and Visual Studio on Windows 7.


• Realize that the Windows documentation is wrong when it comes to "vcvarsall.bat amd64".


• Dig around for a while.


• Find the correct BAT based configuration files and drag them into the application menu.


• Create custom makefiles.


• Scratch your head as Microsoft uses the suffix "32" in paths and library names everywhere.


• More mind numbingly boring rewriting of makefiles.


• Everything compiles, but Winsock related code is broken. Might be configuration. Might be worse.


• Realize that 64bit JRE writes a registry JVM value that points to a non-existent file. My fault ?


• But the code supports that, so just use TEPPEFALL_JVM variable.


• Success!

Posted by JP at 12:46 AM | Permalink

The volume component gives it away. But Silverlight 4 may change that.

Posted by JP at 10:54 AM | Permalink

By being hell bent on "finishing" JavaFX instead of augmenting Swing Sun has more or less destroyed their credibility as a desktop platform company. The reality is that Swing plus a scene graph, accelerated layers and a new media framework is more valuable than the entire JavaFX ecosystem. Adobe, Microsoft, Apple, Opera, Mozilla and Google all believe that XML is the future of layout and yet Sun believes a non-standard syntax based on Lisp and JSON is the way to go. And the fact that C#, Actionscript, Dalvik and Javascript are all Java clones seems to indicate that Java is just fine as a user interface language. Adobe even exports twine animation code as XML and vectors as SVG. I sit here working in Adobe Creative Suite and wonder what Sun is thinking.

Continue reading "Sun is missing out on a huge opportunity" »

Posted by JP at 10:54 PM | Permalink

This is a Remote Desktop screenshot of a brand new Quad Intel i7 / Windows 7 system running 16 FLV movies, or maybe just 14, in Teppefall Media Player (JMC/Swing). It's not usable, but it does run. Still not able to do this in WPF, though. I can only play one WPF MediaElement video stream for some reason. Maybe it's a bug in my code. Don't know.

Adobe Flash will still own the marked, but Sun could get a share of it by fixing the security problems related to Swing. It might be possible to create an FLV player in Java Swing that is faster than a Flash 10 based player. JavaFX might do the same, but only if they put JavaFX inside the JRE. Downloading a 15Mb JavaFX player is not a very useful experience after downloading a 15Mb JRE. My biggest concern is not Windows, but rather OS X people in an infinite bitching loop.

I guess this demo proves that my layout technology is pretty scalable. Though, JMC is still not ready for professional use. There are audio and video synchronization problems everywhere.

Posted by JP at 11:25 PM | Permalink

Here are two similar screenshots. Sun uses a pretty brutal video scaling algorithm and this is a better screenshot than the one below this post.

Sun seems to be in a coma, so I'm only working on the WPF version.

Posted by JP at 10:32 PM | Permalink

Do you know what a guy like me does when Sun Microsystems refuses to release JMediaPane, a Swing API that was announced almost three years ago ? Do I create a lot of JavaFX code and then go into a corner and cry ? No... I create the same media player in Microsoft WPF and C#. That's what people like me do. Yeah, Chuck Norris approves this message !

Continue reading "Java Swing versus WPF running on Windows Vista Chuck Norris Edition." »

Posted by JP at 08:33 PM | Permalink

This is really a stupid test, but I'm showcasing this just to give Adobe a little hint. This my JMC based video player playing four FLV encoded videos versus playing one FLV video in the Adobe Media Player. A lot of memory is being used by the AMP streaming logic, syndication system, image cache, theme system, animation engine and such but the memory usage is still pretty spectacular. But that's not the most shocking issue. The CPU usage is for some absurd reason in the same ballpark. Give or take a few ballparks in scientific accuracy.

Continue reading "Java Swing versus Adobe Flash/Flex" »

Posted by JP at 08:24 PM | Permalink

This is my comment to Bruce Eckel's post Does Anyone Really Care About Desktop Java?. I really enjoyed the honesty in the comments and recommend that people read them.

Swing is difficult because it tries to solve difficult problems. Flex is much more specialized and supports a small subset of Swing's features. If you think Flex competes with Swing you probably also think that “web operating systems” done in Javascript and HTML competes with Windows and OS X. Yes, you can replace a Swing application with a Flex application if the application fits within the feature specification of Flash, but Swing is more similar to QT than Flex.

Continue reading "AMF.. huh?" »

Posted by JP at 10:38 PM | Permalink | Comments (3) | TrackBacks (0)

It was never my intention to write Teppefall applications in Javascript, but here is a simple example on how to do it. The update system, the DSR (Teppefall Runtime) launcher and some Application logic is not available at this time because of dependency problems. It is hard to use Javascript when the concept of a Class is replaced with something else. And working with all kinds of adapter logic is also pretty confusing.

If you want to run this example, just move the /network_app folder into the Teppefall SDK root folder and run Network.cmd or NetworkOSX.sh. This demo showcases plugins, the taskbar icon, layout and basic setup.

You have to download Teppefall Layout to get the original layout file used in this example.

Teppefall SDK Javascript example: network_app.zip

network.js
network_plugins.js

Continue reading "Writing Teppefall applications in Javascript" »

Posted by JP at 07:50 PM | Permalink | Comments (0) | TrackBacks (0)

Memory usage ! I get all teary eyed when I see this. Tamarin seems to be just as greedy as Hotspot.
Well.. at least in this totally non-scientific test. It is beta after all... dude.

Posted by JP at 11:36 PM | Permalink | Comments (1) | TrackBacks (0)

Continue reading "JSlider is stupid" »

Posted by JP at 11:53 PM | Permalink | Comments (3) | TrackBacks (0)

Continue reading "SystemTray and Swing" »

Posted by JP at 10:17 PM | Permalink | Comments (0) | TrackBacks (0)

Sun's Technical Articles and Tips . Tons of Java goodness.

Posted by JP at 10:22 PM | Permalink | Comments (0) | TrackBacks (0)

This blog post by Chris Adamson is a good read. Even got a line or two about Java FX in it.

This guy has been doing a lot (well, more than you) of Quicktime code and understand the boring problems. My addition to his words is that any new audio/video support is not really that helpfull without a new media Applet system or first class Web Start support. The current Applet loader just crashes Firefox over and over again. They have to rethink the class loading system and cut down the number of file reads on the disk. Starting an Applet today is like starting Photoshop.

Web Start is looking better and better, but is still a bitch to debug and still slightly retarded when in sandbox mode.

Posted by JP at 10:40 PM | Permalink | Comments (0) | TrackBacks (0)

You don't have to use Java in order to create Darkstar applications. Here is a simple project I wrote in Python - py_dsi.zip.

Continue reading "Writing Darkstar applications in Python" »

Posted by JP at 08:05 PM | Permalink | Comments (1) | TrackBacks (0)

Darkstar 2D, the system that powers Surface, can also be used in web applications. Here is a simple example in the form of a visual barrier. Darkstar 2D also supports rendering over Java RMI if you need to be able to read Photoshop PSD files on a Mac from a Linux server. The RMI code takes forever to initialize but is quite snappy when operational.

This example is running on a Linux box and uses -Djava.awt.headless=true since it has no GUI system installed.

Code is unreadable

Verification code:

Posted by JP at 03:22 PM | Permalink | Comments (0) | TrackBacks (0)

There has been a lot of broo-ha about Sun's new Java FX platform. Personally I see Java FX as an attempt to move forward on the mobile platform and to replace Java ME with a more powerful Java SE stack, but a lot of people see this as a Flash/Flex/WPF competitor and therefore po-po it as such. Maybe the people at Sun didn't get or read the memo. Or maybe the memo raised an ArrayIndexOutOfBoundsException when reading it backwards. Who knows.

Continue reading "Java FX" »

Posted by JP at 11:45 PM | Permalink | Comments (7) | TrackBacks (0)