Netflix Streaming Coming to PS3 Next Month

[patsu]

I've done a LOT of Java, C#, C/C++ development over the years...and yes, Java is s.l.o.w. It's by design. Interestingly enough, it's actually in the enterprise and appserver (TomCat, etc) sector where it's faster because a lot of the necessities for Java's "write once, run everywhere" mantra are neglected for performance.

Show me your code. ^_^
Thanks to advanced compiler tech, an optimized Java program should be about 5%-10% slower, in exchange for smaller memory footprint, and longer startup time. Back in the days when I was working on compiler tech, an interpreter like this would be 10-100 times slower than optimized C code.

There are many tricks the Java VM implementor can do to speed up execution.
Here's the Java VM Broadcom uses for its Blu-ray chipset:
http://www.myriadgroup.com/en/Device-Manufacturers/Java/Java-CDCA.aspx

You'll see why Java doesn't necessarily add to the overhead, especially for embedded devices.

Some embedded CPUs also run Java bytecode natively (i.e., at native hardware speed).

But in terms of desktop apps, yes, it is slow. It's very easy to see why -- you're running a complicated language through a bytecode interpreter. If you cherrypick some numerical analysis benchmarks, as I'm sure the benchmarks you will cite will do , it won't look too bad because the amount of code present will be negligible and it'll end up being cached and reused. But in the real world, it is noticably slower than most other environments.

Your compiler knowledge is outdated. *Optimized* Java does not necessarily run bytecode interpretatively anymore. It hasn't done so for a long time.

Since the rest of your post is based on obsoleted info, I'll skip it.


Blu-ray performance is slow because of system issues and software issues. I agree it is counter-productive for the studios to replace consistent UI with flashy and confusing graphics, but that's not a Java problem.

I also agree that HD-DVD has simpler DRM. However that is in exchange for Fox not coming on board for HD-DVD. I believe the BD+ DRM was specifically demanded by them. The rest is history.

We should be seeing better and better BD-Live performance as time goes on. Today, we can use BD-Live NetFlix instant streaming with acceptable performance. In a few years times, it should be snappy due to faster hardware.

 

[Asher]

Other than abandoning the whole idea of a programming language for media, what would people want to see in the place of Java? It's not really slower than say, the .NET runtime last I checked (and considerably faster than say, the Python interpreter), and you'd need some sort of VM/interpreter anyway given how heterogeneous the player landscape can get.

C# on .NET is usually faster -- but more importantly, it usually uses significantly less memory. A lot of people will just look at the .NET CLR and the Java VM as functionally similar but there's some language features that can make a difference.

The biggest difference are the support of true generics in C# (Java's generics require lots of casting and unboxing), support for user-defined value types (much faster allocation, no memory overhead and support for ref/out to avoid excessive copying), and also some non-portable features (embed unsafe blocks of code to run natively).

Frankly, I think Java is just too heavy for a lot of its purported users (cell phones, embedded devices...Bluray). I've developed an app on Android in Java (and a Blackberry one...), which isn't toooo slow per se, but it's noticeably slower than native implementations on Android. Google has even made a native-code SDK for Android now for performance-sensitive applications because yes, Java is slow...

I've been developing with WebOS a bit lately and I'm starting to think perhaps it would've been best to go with a JS/DOM approach to Bluray interactivity.

 

[patsu]

Blame it on the programmer first, and then the Java VM used. Does the programmer setup the VM to compile the code natively if he/she needs absolute performance ?

A good one should be able to run your code in native machine code due to the dynamic compiling. OTOH, Google's Javascript run-time (in WebOS) only run on Intel CPU. You won't be able to run it on other non-Intel hardware.

If you read the link above, you'd see how a dynamic Java VM can optimize the run-time for small memory footprint, which makes it suitable for embedded environment.

 

[Asher]

Show me your code. ^_^
Thanks to advanced compiler tech, an optimized Java program should be about 5%-10% slower, in exchange for smaller memory footprint, and longer startup time.

This is patently untrue. Java apps have much larger memory footprints. They need to.

You'll see why Java doesn't necessarily add to the overhead, especially for embedded devices.

It will ALWAYS add overhead, by design.

Some embedded CPU also run Java bytecode natively.

This is true, but at this point why are you even using Java if you need to run it natively to get the desired performance? It's cheaper and easier to use a commodity chipset that's not supporting bytecode natively.

Your compiler knowledge is outdated. *Optimized* Java does not necessarily run bytecode interpretatively anymore. It hasn't done so for a long time.

Since the rest of your post is based on obsoleted info, I'll skip it.

Is it really outdated? I worked at the IBM Toronto Software Lab working on the XL C/C++ & Fortran compilers until 2005. I realize that's four years ago now, but the principles have NOT changed since then that I'm aware of. Since then I've been predominately working on embedded systems (mostly smartphones) which requires me to pay particular attention to things like memory footprints, UI responsiveness, and overall performance with limited CPU power.

I'm assuming you're referring to features like JIT -- which as I understand it, are actually not supported for BD-J.

While I'm not working on compilers anymore, I have a very thorough understanding of Java and the VM. I'm very curious as to why you have waved your hands and declared all of my points to be "obsolete", but we should take that discussion to another thread.

Blu-ray performance is slow because of system issues and software issues.

This is simply rhetoric, I'm afraid. Have you done Java development? Blu-ray performance is slow for the same reason launching Vuze/Azureus is slow, and the same reason Java applets are slow. It's not because the system and software is slow, it's because there's implicit overhead in Java.

I agree it is counter-productive for the studios to replace consistent UI with flashy and confusing graphics, but that's not a Java problem.

It's not a Java problem, but you can't dismiss that from this discussion. It's a problem with choosing BD-J for this purpose -- you give studios too much power, they'll abuse it. It reminds me of all of these people abusing Flash to design websites. This gives credence to the argument you dismissed earlier that BD-J is overkill.

In a few years times, it should be snappy due to faster hardware.

It is very nearly 2010, and the Netflix service and interface are not at all complex. The PS3 has a very beefy CPU in it. The fact that we're still finding excuses for its slow responsiveness should be an indictment on the software chosen for what should be a simple technology, and not the fact that a 3.2GHz CPU with 7 active cores is considered underpowered.

 

[patsu]

This is patently untrue. Java apps have much larger memory footprints. They need to.

What library are you using ? Your footprint is determined by your code size. You don't have to use large libraries you know.

It will ALWAYS add overhead, by design.

This is true, but at this point why are you even using Java if you need to run it natively to get the desired performance? It's cheaper and easier to use a commodity chipset that's not supporting bytecode natively.

The overhead can be low. It works for both commodity and Java-accelerated CPUs.

The dynamic run-time does the native code compile for you. As opposed to say... Google limiting their native JavaScript run-time to Intel CPUs only ?

Is it really outdated? I worked at the IBM Toronto Software Lab working on the XL C/C++ & Fortran compilers until 2005. I realize that's four years ago now, but the principles have NOT changed since then that I'm aware of. Since then I've been predominately working on embedded systems (mostly smartphones) which requires me to pay particular attention to things like memory footprints, UI responsiveness, and overall performance with limited CPU power.

I'm assuming you're referring to features like JIT -- which as I understand it, are actually not supported for BD-J.

Read the jbed link above.

It's not a Java problem, but you can't dismiss that from this discussion. It's a problem with choosing BD-J for this purpose -- you give studios too much power, they'll abuse it. It reminds me of all of these people abusing Flash to design websites. This gives credence to the argument you dismissed earlier that BD-J is overkill.

Even without BD-J, the studios can still create crappy UI. Don't blame Java just because it's the tool.

Without BD-J, we won't be streaming NetFlix today. Is it an overkill to have NetFlix on Blu-ray players ?

It is very nearly 2010, and the Netflix service and interface are not at all complex. The PS3 has a very beefy CPU in it. The fact that we're still finding excuses for its slow responsiveness should be an indictment on the software chosen for what should be a simple technology, and not the fact that a 3.2GHz CPU with 7 active cores is considered underpowered.

I don't think Java runs on the SPUs. It should be running on the PPU. And the bottleneck may not be Java related. There are complex security code to run, and heavy media to load.

 

[Asher]

What library are you using ? Your footprint is determined by your code size. You don't have to use large libraries you know.

I'm not at all referring to the library. I'm referring to the inherent nature of Java. The GC implementation, the fact that every custom data type needs to be an object, the implementation of generics, etc. It's a "fat" language in terms of memory use, independent of library usage.

The dynamic run-time does the native code compile for you. As opposed to say... Google limiting their native JavaScript run-time to Intel CPUs only ?

And what's the result? Google's Javascript run-time completely spanks everything else on the market. So you can see the advantage of that?

Read the jbed link above.

It's all marketing bull. Their product supports JIT, which they market under two different names when used with different config options, and a bytecode optimizer (which is standard in virtually all runtimes). Is this what Bluray players use? I'm pretty sure there's a special BD-J runtime that's required. Even if it IS using it now, it is obviously woefully inadequate given the painful load times on many discs (even on the PS3), and the laggy-feeling UI.

Without BD-J, we won't be streaming NetFlix today.

I was streaming Netflix without BD-J just fine.

I don't think Java runs on the SPUs. It should be running on the PPU. And the bottleneck may not be Java related. There are complex security code to run, and heavy media to load.

It sounds to me like the Java VM isn't optimized, and this is years after its launch. Maybe we should stop using the mantra that soon things will be optimized?

Is it single-threaded only?

The more I learn about this, the more convinced I become it was a bad idea. Entire OSes can boot faster than some BD-J discs take to load.

Edit: I actually had no idea how HDi was designed, but from what I'm reading that's EXACTLY the implemetation I would've used. Utilize the DOM, XML, JavaScript, etc. Provides for a lot of powerful features with extremely low overhead, fast loading time, and good performance. Yeah, you're not going to write 3D games in the thing but it could do everything you're looking for...including Netflix streaming. I see nothing that'd indicate it's not possible. Hell, just last month I wrote a Javascript-powered app that streamed video files over the internet and even added reflections + transformations on them...

The way HDi is designed, it's even possible to embed HDi on media streamed over the internet...like Netflix. Think about that -- interactive menus like you get on the disc but from media you stream from Netflix. What a missed opportunity!

 

[patsu]

I'm not at all referring to the library. I'm referring to the inherent nature of Java. The GC implementation, the fact that every custom data type needs to be an object, the implementation of generics, etc. It's a "fat" language in terms of memory use, independent of library usage.


And what's the result? Google's Javascript run-time completely spanks everything else on the market. So you can see the advantage of that?

It doesn't address the issue of code portability across different Blu-ray players though.
And Java runs on many small memory devices, including smartcards. So I don't think the 'fat' argument works for all environment. It depends on how you (and your library) use it.

It's all marketing bull. Their product supports JIT, which they market under two different names when used with different config options, and a bytecode optimizer (which is standard in virtually all runtimes). Is this what Bluray players use? I'm pretty sure there's a special BD-J runtime that's required. Even if it IS using it now, it is obviously woefully inadequate given the painful load times on many discs (even on the PS3), and the laggy-feeling UI.

Broadcom's Blu-ray chipset uses 500Mhz MIPS 24Kc, and they have licensed jbed.

If you check Blu-ray.com, the Samsung Blu-ray player (based on Broadcom's chipset) has faster overall Java benchmark performance than the 3.2GHz PS3. But it is significantly slower in select operations. e.g., scaling, opacity, loading. My guess is the PS3 "cheated" with the GPU and much faster I/O. Afterall, that box has to stream tons of game assets from Blu-ray.

That's why I said it may be a system (design) issue. We can't just blame everything on the first term we don't like.

I was streaming Netflix without BD-J just fine.

Not on Blu-ray players though.

EDIT: I'd rather people go stomp on the studios' *sses for misusing graphical UI.

 

[obonicus]

I've been developing with WebOS a bit lately and I'm starting to think perhaps it would've been best to go with a JS/DOM approach to Bluray interactivity.

As you said, that's HDi. What exactly makes that faster or lighter? The browser model hardly has low overhead.

Though if we're talking about this heterogeneous environment and limited processors, will we really be seeing JIT compilation, no matter the language?

To go a little more OT, back to .NET, when you were talking about memory, isn't everything in .NET an object? These runtimes really aren't lightweight, they're not meant to be. If you want to go 'lightweight' with Java, use a lot of arrays and primitives. And remove any sharp objects from reach.

 

[flynn]

But in terms of desktop apps, yes, it is slow. It's very easy to see why -- you're running a complicated language through a bytecode interpreter.

You are not, any Hotspot VM will end up running native code. I will concede you slower start up times, but not significantly slower performance.

Frankly, I think Java is just too heavy for a lot of its purported users (cell phones, embedded devices...Bluray). I've developed an app on Android in Java (and a Blackberry one...), which isn't toooo slow per se, but it's noticeably slower than native implementations on Android. Google has even made a native-code SDK for Android now for performance-sensitive applications because yes, Java is slow...

Android is a very bad example and should never be used to show Java's slowness. The Dalvik VM is a piss-poor performing hack that doesn't support JIT and makes a lot of trade offs. A proper VM would perform much much better.

 

[eastmen]

To be fair? To be fair that is a bullshit, unless you want to add the other bullshit claims into this thread.

The best format won, that is the only fair thing to say.

If that were true we'd have hd dvd which was $100 two years ago and put out just as good image quality and had cheaper media and came with the dvd on the same disc long ago.

 

[bkilian]

Your memory is hazy or didnt read the topics, Check posts from a few years ago in these forums, some ppl that are still posting on these forums were a few years ago picking HD-DVD to win the format war, personally I remember posting the chance that blu-ray would triumph was 99%.
The reason being twofold.
A/ They had far more of the major studios compared to HD-DVD
B/ The ps3 trojan horse

I perhaps phrased it a bit incorrectly. I should have said "Anyone who actually _knew anything_ about the formats" And you almost lost your 99% bet, It was down to the wire at the end there. We _almost_ had Fox and Warner switch. The BD guys did some amazing footwork to stop that and reverse it.

The first studio to jump ship after the initial positioning and the first studio to screw their customers over was Paramount, and lets just pretend everybody was paid off, then HD-DVD shot first with their bribe and got killed when it backfired when universal was bought out.

I am still avoiding Paramount titles, i grew to hate them enough to do so. What i might have bought at launch now gets in the back of the line until i find a good offer.

How things really went down, no one knows, both "paid off" were rumours STRICTLY comming from the internet, i recall the source of the Universal buyout as a blog? by someone that was in the know?, and the amount was 500 million, and that was known pretty much the same day it was announced.. incredible ehhh. Not a creditable online paper backed that up, afaik. And that shouldnt be a surprise, the deals made on both sides should and could only be secret.

You are correct, the Paramount switch was quite unexpected to the Bluray side, alhough it shouldn't have been, one of the reasons they switched (other than the sweet deal from Toshiba) was that Sony refused to give them the same disc manufacturing incentives and priorities as other studios were getting, so it was costing them a lot more to do a run of BD discs. The other studio to switch (with it's sweet deal from Sony) was Warner, not Universal. That was a sad day in our offices.

Man...I've met James Gosling and listened to his hardcore philosophy re: Java first-hand, I've programmed in Java on and off since 2001. By it's very nature, it'll never be a speed demon. You're going to be running bytecode interpreters on all of these devices, and the CPUs they're putting in these dedicated Bluray players are actually not that beefy.

Around 600Mhz dual core ARM processors if they use the Broadcom chipset, which quite a few do, similar stats for the Sigma. The processing power is decent, but the VM and libraries still need a lot of work. They've still come a long way since the first releases, especially the disney ones that took 10 minutes to load and then ran out of memory on anything other than the PS3.

I'm not saying it'll be unacceptable, but it is a bit annoying. I was hoping we'd be done with the laggy-feeling experience we're used to with DVDs, but so far on Bluray it's still there. The custom menus are more responsive on the King Kong HD DVD than they are on most of the Blurays I've seen, for example.

I remember going up to Burbank and helping Deluxe debug that menu system, man there were some amazing hacks keeping that thing working. Most of the developers working on those titles had just come off working on PSP titles. Ironically, HDi and the PSP Movie format are surprisingly similar, both using XML and Javascript. Its probably why Sony supported HDi in the BDA, but was overruled by the other members.

Edit: I actually had no idea how HDi was designed, but from what I'm reading that's EXACTLY the implemetation I would've used. Utilize the DOM, XML, JavaScript, etc. Provides for a lot of powerful features with extremely low overhead, fast loading time, and good performance. Yeah, you're not going to write 3D games in the thing but it could do everything you're looking for...including Netflix streaming. I see nothing that'd indicate it's not possible. Hell, just last month I wrote a Javascript-powered app that streamed video files over the internet and even added reflections + transformations on them...

The way HDi is designed, it's even possible to embed HDi on media streamed over the internet...like Netflix. Think about that -- interactive menus like you get on the disc but from media you stream from Netflix. What a missed opportunity!

Indeed. And that was one of the purposes of HDi that we never got around to getting off the ground. I still prefer the 0.8 version of the spec before the movie studios got hold of it and started making silly demands. The original version allowed for almost full fuctionality with no JS at all, by allowing the XML to specify standard functions to be performed at certain actions. It was designed for streaming media in mind, as well as simple and fast menus that could be hardware accelerated.

The very first working HDi app ever was actually written by me, and consisted of a badly animated bird flying across the screen. Used no javascript at all, all in XML.

Even with the final spec, there were quite a few different ways to get things done. The Universal titles were XML heavy with just enough Javascript to perform actions, most of the animation was pure XML and SMIL. The Warner titles did almost everything in script using timers and callbacks. It was fascinating to see how studios took the spec and ran with it.

I still have the spec in my office. It's multiple letter sized books that when stacked are about 5" high.

 

[bkilian]

As you said, that's HDi. What exactly makes that faster or lighter? The browser model hardly has low overhead.

Well, what made the HDi model faster and lighter was the fact that the XML primitives could be hardware accelerated, and all graphics drawing, image loading and animation was handled by optimised native code. Javascript is also an extremely simple language to implement, essentially everything is just a set of name-value pairs. As Google and Firefox has shown it's also possible to make it very fast. We didn't go all the way there, but our JS engine was no slouch. Our "standard library functions" were simple and limited, unlike the bastardized MHP/Java TV libraries you have to include when building BD-J apps. This made it harder to do weird stuff, but also meant that for normal use cases, we used less memory and were far more likely to work identically across multiple devices.

 

[makattack]

Well, what made the HDi model faster and lighter was the fact that the XML primitives could be hardware accelerated, and all graphics drawing, image loading and animation was handled by optimised native code. Javascript is also an extremely simple language to implement, essentially everything is just a set of name-value pairs. As Google and Firefox has shown it's also possible to make it very fast. We didn't go all the way there, but our JS engine was no slouch. Our "standard library functions" were simple and limited, unlike the bastardized MHP/Java TV libraries you have to include when building BD-J apps. This made it harder to do weird stuff, but also meant that for normal use cases, we used less memory and were far more likely to work identically across multiple devices.

Thanks for the info. This is what I can really appreciate. Engineering with simplicity (which is a relative term) and balanced efficiency.

Again, I can appreciate Java -- heck, I've been programming in Java since 1994, and as I said, do get a kick out of writing a deploying my own Java applications on my Android G1 T-Mobile phone, but *no one* will ever convince me that it's performance in general is on par with native, compiled code. First off, performance is more than just how fast instructions are executed, in my book.

The reason why I like Java, is funny enough, the very reason why it is not ever going to provide the best performance: portability, usability, reliability.

When I wrote applications that required maximum computational speed with minimal memory usage, I always went with the assembler for whatever the target processor was.

If I wanted better code re-use/readability (ie: usability), I went with C or C++.

If I wanted to quickly write code without worrying too much about nit-picking my memory usage/model and having a lot of libraries from which to rely on, I go with Java.

My career has went from demanding real-time systems programming to mostly business application and simulation development that doesn't require responsive/fast results -- just accuracy. This means that Java or any other very high level/virtualized environments are most ideal for me.

I can certainly understand why Java was selected for the BDJ/Live stuff, but I honestly think it's overkill and just not the best engineering option for devices that won't necessarily have the CPU and memory of a desktop computer.

 

[obonicus]

Well, what made the HDi model faster and lighter was the fact that the XML primitives could be hardware accelerated, and all graphics drawing, image loading and animation was handled by optimised native code.

We're comparing to Java, though. All of that can be done through libraries implemented in native code. Of course, native code becomes a problem when you start to have vendors with significantly different solutions.

Javascript is also an extremely simple language to implement, essentially everything is just a set of name-value pairs. As Google and Firefox has shown it's also possible to make it very fast.

Sure, but that's true of Lua or even Python (all classes just dictionaries with special syntax) -- JS/ES also has a lot of unfortunate baggage. And very fast is highly relative; if we allow JIT compiling and a decent optimizing compiler, anything can be really fast. How realistic is to run a compiler like that on a more limited processor? If someone buys a cheaper, slower BD drive would they tolerate a long wait before their menu system responds to them the first time?

There was a complaint was about datatypes and the overhead incurred by them, it's weird to bring up javascript and DOM.

We didn't go all the way there, but our JS engine was no slouch. Our "standard library functions" were simple and limited, unlike the bastardized MHP/Java TV libraries you have to include when building BD-J apps. This made it harder to do weird stuff, but also meant that for normal use cases, we used less memory and were far more likely to work identically across multiple devices.

You can use libraries other than the javatv stuff but that may not be safe for compatibility reasons. I'll grant you that J2ME/java tv is not a great choice, I just don't think it's any worse than HDi when it comes to performance. (Ease of use is a different story.)

 

[-tkf-]

one of the reasons they switched (other than the sweet deal from Toshiba) was that Sony refused to give them the same disc manufacturing incentives and priorities as other studios were getting

Were these studios those that chose Blu-Ray from the start? Then Paramount should have chosen side a bit earlier, oh well, those that get the last laugh i guess.

Hahahaha ;-)

 

[wco81]

I haven't tried the BD-Live content, although I have discs like Dark Knight and Wall-E.

Nor have I kept up on standalone players but are there players which also have Netflix built-in with BD_Live support and as fast-booting of BD as the PS3 by now?

I don't know why anyone who was interested enough in quality to get a BD player would settle for the poor selection and quality of Netflix streaming though.

 

[Asher]

As you said, that's HDi. What exactly makes that faster or lighter? The browser model hardly has low overhead.

It has significantly lower overhead than a VM, and significantly lower start-up time to JIT-based VMs.

To go a little more OT, back to .NET, when you were talking about memory, isn't everything in .NET an object?

No, .NET gives the illusion that everything is an object for simplicity. In Java you need to cast a double to Double, for instance, to perform operations on it aside from the basic arithmetic types. In C#, it's a primitive but the language/CLR will box/unbox it for you seamlessly. It's just syntactic sugar, not a true "everything is an object" environment.

These runtimes really aren't lightweight, they're not meant to be. If you want to go 'lightweight' with Java, use a lot of arrays and primitives. And remove any sharp objects from reach.

From what I see in the BD-J spec, it's very object-heavy.

Android is a very bad example and should never be used to show Java's slowness. The Dalvik VM is a piss-poor performing hack that doesn't support JIT and makes a lot of trade offs. A proper VM would perform much much better.

JIT on a mobile device would be a terrible idea. The loading time would be unacceptable and I'm sure it wouldn't be terribly good on the battery life.

Perhaps if the JIT was integrated into the install process it'd work better -- when you download the app on your phone and it's "installing" it'll JIT just the once and cache the code. Kind of like how Paint.NET works with .NET on Windows.

 

[Shifty Geezer]

I don't know why anyone who was interested enough in quality to get a BD player would settle for the poor selection and quality of Netflix streaming though.

Convenience. Much as I like some BRDs, some movies really don't require it, and if you just fancy a particular flick at a particular time without caring to own it, a DVD-quality stream is plenty good enough.

 

[Asher]

Definitely. I rent blurays (3-4 a week), but I also frequently watch movies on-demand on my cable box. They're in HD/5.1, but not at the same quality as the Bluray...but the convenience is unmatched. Especially because my on-demand service is similar to Netflix in that it's free per movie (it's included in my movie channel subscriptions), just with smaller selection that changes ever couple weeks.

 

[patsu]

Java can be hardware accelerated as well as HDi. The problem is it will bump the BOM cost. There is little speed advantage for HDi/JavaScript when compared to an opimized Java VM (There is GC in JavaScript too ). You can run native code in Java like you do in JavaScript, without tying to a particular CPU (family).

The library would make a difference, but a good Java VM should be able to prune unused libraries just like the jbed one, even at compile time. This depends on the VM vendor though. For people with bad experiences in Java, my guess is they rely mostly on popular libraries that focus on ease-of-development, and flexibility, hence there are a lot of overhead.

The second thing is because Java is an open standard, we will get more variance in VM implementation. The HDi stack is a single provider solution despite some effort to standardize it. When there are more implementations, we will likely get shoddy ones too (Unless everyone goes to the same vendor ).

At the end of the day, it's up to the programmer. If he relies on third party heavy weight, inefficient library, then it'd be slow.

HDi has a fixed, simpler library. Unfortunately, we don't get to see any instant streaming service written in it. BD-J provides much more flexibility for the studios to explore their creativity. I will always value that since it does not artificially limit the developers.

If people just want a simple interface, Blu-ray has a simpler interface language too (although that doesn't support PiP). BD-J is there to provide an open-ended environment.