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