Ramblings of a coder

The massive scalability of modern GPUs has led to many things, from Bitcoin mining to folding@home, seti@home and various other general purpose tasks that involve huge amounts of number crunching. While not as flexible as CPUs, modern GPUs can be hugely scalable thanks to the massive number of stream processors they contain. I've long been impressed by the technology, and long known that to implement something using it you can use CUDA and/or OpenCL. For about the same amount of time there have been low level Java wrappers too that mean you can execute OpenCL without resorting to native languages - even if it meant you had to write the OpenCL directly, as well as huge amounts of boilerplate code to interface with it. Of course, if you wanted your application to work in the real world, a completely separate load of code for it to fall back on if the device didn't support OpenCL was needed too. For about the same amount of time, I've thought that what we really need is a ...

I originally took a quick look at the original JavaFX when it was first announced. When I heard the concept I thought it sounded interesting to potentially use on the desktop front but on the web front it was a no-no. Perhaps I'm wrong, but I honestly think HTML5 will rule the roost there and JavaFX is really too late. I also really didn't like the scripting language - some people do and I can see it's benefit, but for an application that I'm creating fully it created a bit of unnecessary complexity in my opinion. Anyway, this was all a few years back now and for a number of reasons, but primarily because it looks a promising technology for an aspect of my PhD, I've been giving it another look. I've wanted to ever since I saw the impressive keynote demo last year, but hadn't had the time to really get into it. For the last few weeks however that's changed and I've been playing away! Initial impressions, I have to say, are good. It is now of course f...

This post is really a follow on to the last, so if you want a bit of background give that a read through. In it I basically talk about the various options I came to when trying to implement video support in Java, and how I felt the best way to go was using out of process players and VLCJ. Before I get to the code, a warning - while this isn't stupidly hard, it's definitely not for beginners. If you're competent with Java in general you shouldn't have any trouble following - but this is not a cut / paste / forget the advanced stuff job! Eventually and depending on interest I may look into packaging it up into an easy to use library and distributing, but that day is not today! Secondly, this code is literally cut straight out of Quelea and at the moment is: Largely uncommented From an unreleased version Not the best quality May contain Quelea specific bits that don't apply Eventually, it'll all be refactored into beautiful OO-like niceness. But in terms of the con...

A while back I posted whining about the lack of decent video support in Java, and the fact that try as I might I just couldn't seem to find a decent one. I wrote this as part of my struggles trying to get video implemented properly in Quelea . The good news is that the trunk version of Quelea seems to have decent, cross platform and reliable video that's compatible with any format you throw at it. And it's all thanks to the VLCJ / VLC guys. The bad news is that, well, it's not as obvious or as easy as it might first look. Before I go into details however, I think an honourable mention goes to Xuggler . It was the first package I really tried that seemed to be getting me somewhere - with really quite little effort after watching the tutorials I had a basic video application going that could play most file types. It couldn't do any seeking, pausing or the like but that I thought would be relatively easy. And, guess what - once again I was completely wrong. See, Xuggle...

I'm slowly coming to realise just how much Sun seemed to like the "let" suffix. We have applets, servlets, midlets, Xlets - and just as I think I'm running out, I discover doclets and taglets! It all started when, for our final year project, we decided to use the convention of an "@qa" annotation with a set format in the javadoc at the start of each class file to document who had QAed the file and when. It works well just as is (and this is how we were intending to leave it) but a part of me couldn't help but get slightly annoyed at the copious amounts of javadoc warnings this produced. I wondered if there was a way to not just shut javadoc up, but to sensibly extend it so it knew about this extra tag and could write out some meaningful information to the resulting HTML. Although this is rather poorly documented, it turns out it can, and it's really quite nice to use. Initial searching led me here , which provides a brief overview about taglets (but ...

Well, this one wasn't the toughest by any stretch. But it does highlight some weird syntax that's possible (though highly frowned upon.) Rather than putting the square brackets that signal the return type is an array straight after the return type, these can also go after the method declaration. So it's exactly the same as: public class Test{ public byte[][][] functionArray() { return null; } } So yes, it compiles and runs fine. It's a bit of a weird design choice this one - these days it's just there for backwards compatibility, and even the JLS goes so far as to say it shouldn't be used in new code. So stay away from writing it, but if you see some weird old code like this then don't be too shocked :-)

This is a quickie, answer will be posted in due course. Does this compile, and why / why not? public class Test{ public byte functionArray()[][][] { return null; } }

One of the possible future features I've always had in mind for Quelea is decent video support. The ability to import and display avi or mkv files, or to play a clip seamlessly from a DVD. This isn't really something I'd done previously, so I was interested to see the options available. All things considered, I thought that it's such a common thing to want to do there must be one or two good, well accepted libraries around at handling all of the media side of things. I was wrong. Very wrong! Considering that I want a cross platform way to do all the above, the amount of options available are considerably limited. The classic one is the JMF, which is probably the best option around. This doesn't mean it's good however - it's woefully outdated, the APIs aren't the best to work with in the world by a long shot and every other question about it asked online seems to end up with something along the lines of "wow, you're using JMF? Good luck..."...