Thanks for looking at it!
- We have most of the infrastructure to support JAWT with the "new"
I'm afraid I don't fully understand. If I remember correctly, the
"new" CALayer model was fully working...
That was more a note that we're already on the new model and shouldn't need
to replace NSView anymore, like other projects still had to.
- The attaching/detaching of the CALayer from Java in our code is broken
Could I please ask you for details? I see that you've introduced a
id<JAWT_SurfaceLayers> sl but it appears to only be assigned to and
Sure. There are multiple issues:
- If the CALayer is repeatedly attached from within paint(..), it doesn't
work at all. The only thing that worked was to attach it from within
addNotify. This makes sense because the Javadoc of addNotify says that it is
called from the framework when the native counterpart is ready.
- The sl field is read when closing the native part, line 57 in the patch
- Without that, the CALayer will stay around for as long as the window is
- Closing has to be called from removeNotify
- We have problems with the z-Order (because AWT uses lower numbers as
top-most index, contrary to every other layering system including
CoreAnimation (and ironically Swing as well))
Is it easy to fix (in the context of JAWTRenderer, of course)?
Well, easier than all the rest I guess. The problem is that we don't really
know how many components will be added to the container, so a
Abs(count()-index()) doesn't do the job and why I hacked a string comparison
for "LOCAL" into the Java part of the JAWT component to set a high index.
- JAWT is a heavyweight component while Swing components are
lightweight, so it will most likely never be possible again to position
a button on top of the videos, despite the announcement in 
We don't try to address that with JAWTRenderer.
No, but we run into it because JAWTRenderer is heavyweight and the button to
close the local video preview is lightweight. However, I would consider this
button the least of our concerns as we still have the toolbar button to
show/hide the local video.
Given all these troubles, I wonder why we don't just resort to draw the
received image with Java2D, which internally uses CoreAnimation and
We introduced JAWTRenderer for the purposes of performance. It gives
us the ability to one day keep the whole video frames out of the Java
heap and into native memory.
Sure, but we don't have the hardware decoding feature ready (Sebs old branch
for that doesn't even have an attempt for OSX). Given that we want to move
away from Swing/AWT at some point and the current focus is entirely on Meet,
I don't really see anyone addressing that in the foreseeable future.
I didn't notice a major difference in performance while swearing at
Could you please share a bit more details about the scenarios that you
This was just a one to one call and certainly not exhaustive testing. But
AFAIK the conferences have always been problematic anyway?
What makes a difference though is that Java 8 now uses OpenGL and CALayer
internally for drawing with Graphics, so there is no difference anymore in
what the JRE does over what we're doing.
The attached patch
- Implements a plain Java rendering which can be enabled with a property
(almost fit for commit)
FMJ implements pure-Java video Renderers
(./src/net/sf/fmj/media/renderer/video/). If memory serves me right,
one of them kicks in and does a good job if JAWTRenderer fails to
register. Have you looked at them? If one of them works for us
alright, could we please not re-implement it in JAWTRenderer?
Nope, didn't know about this. Will take a look, thanks for the hint.
- Brings the JAWT rendering back to life against Java 8 (with some hacks,
definitely not fit for commit)
I will appreciate explanations here because I do not understand the
patch. (I guess the changes to src/native/build.xml are OK because you
supposedly used them to rebuild the jnawtrenderer binary.)
Well to be honest I don't understand all of it either. Without the patch, I
only see a black window. So I took Apple's JAWTExample, saw that they only
register the CALayer once, adapted this to libjitsi and got a picture again
(apparently this is new to Java 8 as in Java 7 it was only the z-index that
caused problems). But with these changes, the layer stayed on the screen
even if the components were closed - so I had to set the layer to nil (hence
the sl field).
Hope that makes a bit more sense...?
The build.xml changes are for compiling against Java 8, but I didn't use
them much as I created an XCode project to be able to debug the native code.
Lyubo, you wrote most of that code. What do you think?
And all the other devs would be most welcome to state their opinion as
and not remain silent.
I'm very happy that we're looking into moving to Java 8.
Please consider my comments complementing, not opposing.
Oh not at all!
2014-11-16 23:20 GMT+02:00 Ingo Bauersachs <email@example.com>: