Exposing native surface or opengl handle

Matthias Hänel haenel at ultramixer.com
Thu Jun 26 08:54:56 UTC 2014


Hey John,


Am 26.06.2014 um 10:23 schrieb Robert Krüger <krueger at lesspain.de>:

> On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx <hjohn at xs4all.nl> wrote:
>> 
>> On 13/06/2014 08:57, Robert Krüger wrote:
>>> 
>>> Hi,
>>> 
>>> it has been discussed a number of time in the passed but let me
>>> quickly summarize:
>>> 
>>> A number of people have requested a feature that provides the ability
>>> to have native code draw into a surface provided by a JavaFX
>>> application as fast as technically possible, i.e. with no indirection
>>> or copying because use cases for this were mostly cases where
>>> performance was critical, e.g. HD/UHD video players, real-time
>>> visualization etc. where losing even e few percent would make a
>>> software written in JavaFX unable to compete with native products
>>> (e.g. in the video area nobody will use a video player that is not
>>> able to play the content smoothly that VLC player or Quicktime can on
>>> the same machine).
>> 
>> Although copying is used, I've combined JavaFX and VLC in this fashion for
>> over a year already, and video is smooth and stable -- stable enough to
>> watch full length HD movies, at 20% increased speed (the speed I normally
>> watch them).
>> 
>> Of course, if the target machine is barely able to play these, then the
>> extra copying overhead (which is smaller than people think) may be too much.
> 
> Yes and this becomes more and more a problem of not so weak machines
> when you go to higher resolutions than FHD that you can display well
> on a Retina display and thus a competitive disadvantage when targeting
> that market. I agree that for a lot of video applications the copying
> approach is probably good enough, though.

Well, from my perspective it is always a bad idea to memcpy whenever you can avoid it ;)
Our applications do a lot more than just display a video image. I really don't want
to have a bottleneck by design. 


Matthias



More information about the openjfx-dev mailing list