search

caprica / vlcj

Java framework for the vlc media player
http://www.capricasoftware.co.uk/projects/vlcj
1.13k stars 259 forks source link

Investigate JNA direct mapping #374

Closed caprica closed 5 years ago

caprica commented 9 years ago

For performance improvements.

caprica commented 9 years ago

Direct mapping seems quite easy to implement and seems to work.

Only thing not supported that vlcj uses is String[] as a native method parameter (e.g. for libvlc_new).

Cases such as that (there are I think 5 of them) can just fall-back to the interface-style binding for those functions only. Or there may be a JNA solution for that.

caprica commented 5 years ago

There's not just the LibVlc interface, there's also:

Some of these could be migrated to direct mapping before the bigger task of LibVlc itself.

caprica commented 5 years ago

I'm going to punt this to some time after vlcj-4.x

caprica commented 5 years ago

After some experimentation with this (as far as LibVlc goes), some observations...

  1. String[] parameters are not supported, but handily JNA provides a StringArray class that seems to do the trick, and this is only really needed for libvlc_new
  2. It was pretty much straightforward to implement this

It might be possible to consider this for vlcj 4.1. Not sure.

caprica commented 5 years ago

There are two options, static vs instance methods.

Instance methods matches most closely the situation we have now (with the interface)

libvlc.libvlc_new(...)

With static methods this becomes...

LibVlc.libvlc_new(...)

Or with static imports:

libvlc_new(...)

Using static would mean we do not have to pass around a LibVlc instance through a lot of method signatures.

However, changing this will likely affect a lot of classes.

caprica commented 5 years ago

A downside to the direct-mapping is that if at run-time the native library that is loaded is missing any declared static native method in the Java implementation class it will fail with NoClassDefFoundError.

This is a misleading error message, we can try and throw out a more meaningful exception.

Previously the missing native function would not be detected until it was actually called - which was useful for the case where an older version of the native library was used.

On balance, this load-time failure is probably safer, but it is worth keeping in mind.

caprica commented 5 years ago

Slated for 4.1.0, 0e9fb5a756fd326cce9b038488133aaf2dad2178