That's my point, isn't it better to use a proven solution instead of rolling your own? You also get batch processing, configurable wait strategies and dependency chaining out of the box.


I don't see the point of what you're saying. It's obvious that it's not as fast compared to having a single producer, but it's many times faster than an JDK BlockingQueue in the multi-producer case. CAS-on-insert is much better than a lock and it's not the only thing that the Disruptor gets right (PoT size to avoid divisions, false-sharing elimination, etc, you do these things in your implementation too).

Disruptor development, after the initial release, was mostly driven by exactly this case, multiple producers. Even as early as when instantiating a RingBuffer you have to choose between the two major use cases, see the createSingleProducer and createMultiProducer methods. The MultiProducerSequence class is what takes care of multi-thread publishing in the current version.

I was reading this recently, it might help you a bit. It's written in JS/WebGL, but the techniques used apply equally well to desktop GL.

The reduced state changes will improve rendering performance, but you'll have to deal with a lot of complexity and performance issues when updating the bigger VBO. Mutating a VBO while it's still being used for rendering by the previous frame is tricky (see Riven's streaming VBO updates).

It's a decent bandwidth win, but you should prioritize other optimizations first.

Yes, sounds a lot, especially without LOD.

Yes.

This is a must imho. It should also improve quality, by reducing geometry aliasing artifacts. GPUs don't like sub-pixel sized triangles.

This is waste I think, unless you need really fine detail up-close.

You can do this in OpenGL, yes. Different vertex data can come from different VBOs. It's not as useful as you'd imagine because you can only have a single index stream for all VBOs. You can do more fancy stuff with uniform buffer objects, but then you'd have to increase minimum GPU spec requirements.

Bonus tip: VAOs are shit. It was a bad idea and performance suffers across all vendors and implementations. Create and bind one on init and then forget they even exist.

Nice read.

Have you considered using the Disruptor for your queues? Unbounded queues enable simpler APIs but are almost always a bad idea. Just copy the behavior of Go's channels; no capacity and you get a SynchronizedQueue, otherwise you get a bounded queue. You should be able to emulate a SynchronizedQueue using the Disruptor, then you only have to document that capacity has to be a power-of-2. But I guess you already require that in your bounded queue implementation.

This is normal and a better GPU won't eliminate the framebuffer read-back. The point of this demo is to enable integration with zero changes to JavaFX and to showcase what such an integration could be used for. The overhead you're seeing is probably too much to use in production, especially on low-end hardware.

Possible changes to JavaFX that would make it more viable:

- Better PixelReader/Writer API to allow for zero-copy read-back loops. This would reduce memory/CPU pressure, but won't eliminate the read-back (+ upload).
- Exposure of the internal GL context to enable GPU copies via WGL/GLX make_current_read or NV_copy_image.
- Exposure of the internal GL context and also of any FBOs or textures used for JavaFX rendering. These could be used directly without any copies via context object sharing.

The last 2 would also require rendering synchronization APIs and a flag that forces OpenGL rendering, even on Windows.

No, the menus appear above the LWJGL display.

You can use Display.isDirty() to determine when such a repaint is required. It works fine with both JMenus and JPopupMenus. Something that didn't make it to 2.9 and will appear in the next nightly build is that LWJGL will now properly close any open menus when you click on the canvas.

Hi Krux,

First of all the integration in this demo is 2-way; you have both JavaFX nodes rendered in a 3D scene and the 3D scene itself rendered as a JavaFX node. This is the worst possible scenario in terms of performance and probably unrealistic in a real application. If you only need JavaFX content in an LWJGL window that's possible of course.

You're correct that GUI elements don't need to be redrawn as frequently. Again, I chose a WebView on purpose because I needed to test the most demanding node possible to see if this approach is viable. I do in fact use a texture to cache the JavaFX rendering, but in this demo it's being updated whenever I detect a change in the HTML content *or* every 4 frames (at 60fps), for carets etc. In a real app you could reduce the update rate considerably.

JavaFX does have a fully working robot implementation, but it's currently undocumented. You can use com.sun.glass.ui.Application.GetApplication().createRobot() to get an instance and start firing events. I'm afraid I can't help you with transforming 3D scene coordinates to 2D node coordinates, that's scene/engine specific, but it should be easy as long as you know the transformation matrix of the surface that contains the JavaFX texture.

Remove the existing manifest folder under RuinsOfRevenge.jar. Then click on RuinsOfRevenge.jar and the Create/Use Existing Manifest buttons will appear.

IDEA uses JDK7's WatchService since version 12, so mostly no. You can even change the project metadata files and it will pick-up the changes. Exceptions:

- A project reload is required when you change the project language level (e.g. switching from JDK7 to JDK8 lambdas), but that's very rare.
- A restart is required when enabling/disabling plugins and when invalidating the caches (also rare).
- A manual "Refresh File Status" action is required if you happen to do VCS actions outside the IDE.

The built-in way to do it is with an intention: alt+enter => Introduce local variable. Not sure if alt+enter works with the Eclipse keymap. Also, this intention should be the first one almost always, so it's a quick alt+enter+enter.

Alternatively, you can use a Live Template (another one of my favorite IDEA features). I tried the following and it seems to work ok, but there might a better way:

Abbreviation: auto
Template text:


Template variable setup (the order is important):


Options: +Reformat according to style
Scope: Java statement & declaration.

You use it by typing: "auto" + <expand with character> + type the expression + <enter> + type the variable name.

appel, why not switch to an Eclipse keymap like ra4king did? It's even built-in (also has Netbeans, Emacs and more).


I never use either. ctrl+c without any selection copies the entire current line. I then paste (ctrl+v) to duplicate. Same for delete, either ctrl+x (cuts the entire line) or shift+delete (deletes entire line).


I can't comment on performance without knowing specifics about your setup, but I definitely don't see this happening locally. Also, I will gladly trade a slight performance penalty for extra features. Right-click in source code == context helps refine the list of options available. Context-sensitivity is something that IDEA gets right and does better than any other IDE.

Obviously there is a trade-off to be made here between performance and features and that's a personal choice. But horror stories about performance are usually the result of some broken plugin or wrong setting.

About the LnF, Darcula's contrast is not enough for my eyes. I use Swing's native OS look'n'feel (Windows in my case) and it looks fine to me.

Also keep in mind that the first time you open a project or set up a library/JDK, IDEA starts indexing it in the background. Performance and functionality will be degraded until indexing completes.

For performance, I recommend the following:

- Disable any plugins that are not useful to your work.
- Configure inspections to your needs. The best approach is to use a different set of inspections for on-the-fly editor highlighting and a different one for "offline" analysis.
- Same for intentions, you may want to disable the uninteresting ones.
- Disable or tune the delays of the automatic re-parsing / code completion / parameter info popup.

Not sure why you need that. Press <end> on an empty line (or <enter> on the line before) and the caret will move to the correct indentation level for the current scope.


Try glVAP <ctrl> + <double space>. You'll still have to do the static import intention, but I bet that just blew your mind.


The Community edition is free and good enough for anything, unless you do web development. The killer feature is its editor.

I'm trying to make a living in Greece. Your argument is invalid.

OpenCL can be used for anything really, but interop with OpenGL is still problematic. Sharing buffers is easy enough, but when it's time to synchronize CL computation with GL rendering, we're forced to use clFinish/glFinish, sacrificing performance. It's been almost 3 years and no vendor supports ARB_cl_event or KHR_gl_event yet.

ARB_compute_shader, which is compute via OpenGL/GLSL, might be a more approachable (and obviously less powerful) solution. There are no synchronization issues and you won't have to learn another API. Only Nvidia supports this currently but we should see support from other vendors soon. Unfortunately the spec has bumped the required GL version to 4.2 (was 3.0 originally), so hardware support will be limited.

According to this, Mojang is working on a PS4 title. I guess they're big enough to switch to a non-JVM dev environment, but it's a little glimpse of hope.

JavaFX exposing a 3D API doesn't change anything for integration purposes, since it's at a level higher than the interesting stuff.

Speaking for LWJGL, we're exploring different options and we won't commit to anything until we try to integrate with JavaFX properly. We're currently waiting for Prism and Glass to be fully open sourced, then we'll see what's possible. There's been a lot of progress with the open sourcing of JavaFX (details here), but we'll have to a wait a few more weeks for Prism.

Sorry about that, I used T[] b (instead of T b) when I tested.


Indeed, the first test fails on JDK 7, but works fine on JDK 8. Will try to find if there's been a bugfix in 8 related to that.

Edit: Seems like a javac fix. Compilation output for test1:

You can get rid of that warning with @SafeVarargs on the alloc method. Requires Java 7+.


Actually it's the second call that throws a NPE. The first one works fine. I tested the wrong code.

Here's a nice article on lambdas and what they mean for the JDK libraries and the code we write.

Note that the latest jdk8 lambda-enabled builds already have some API changes compared to the article. For example Block<T> is now called Consumer<T>.

As I said, I can see how thinking in-order can be more intuitive. But I have a problem with this:


There's a conflict between what you describe and the actual math. Say the flowerpot rests at +10 on the x-axis. If I were moving objects around, I'd do a glTranslatef(-10.0f, 0.0f, 0.0f). Instead, I have to do a glTranslatef(10.0f, 0.0f, 0.0f), that is, I'm moving the origin to the object and not the object to the origin. Not sure if I explain to correctly, but you're still visualizing one thing and writing code that does the opposite.

I too prefer to think in terms of what happens to the object, inside its parent coordinate frame. With your model I have to think about what happens to the coordinate frame instead, the math forces me to.

You'd never do that in real code anyway. You'd animate a quaternion and a position vector and you'd build the final matrix from those two in a single step (then use either LoadMatrix or UniformMatrix4x4). For someone new to OpenGL though, using the fixed functionality without a vecmath library, I think it's much easier to get them started with "whatever it is you've visualized in your head, write the code in reverse".

I appreciate your mental model and I really liked what you said about "every transform you apply transforms all other future transforms". But I think it gets confusing when you have a combined MODELVIEW matrix like in OpenGL. Let me explain:

a) The reverse model. You always pretend you're in local space and want to apply some transforms. When writing the code for it, you reverse the order. Continuing with the above flowerpot example:

We start in the flowerpot-local space and then

• We apply a rotation to tilt the flowerpot to the left (glRotate)
• We apply a translation to move it to the right (glTranslate)

We don't care what happened before getting to this model, when writing the code for this, we simply reverse the order:

• glTranslate
• glRotate

b) The transformed coordinate frame model. You start at the origin (0, 0, 0). If you want to apply a local transform (the rotation), you first need to transform the global coordinate frame so that is matches the local coordinate frame:

We start in global space and then

• We apply a translation to move the origin to our flowerpot (glTranslate)
• We apply a rotation to tilt the flowerpot to the left (glRotate)

This is nice, since it exactly matches the code we have to write (same as above):

• glTranslate
• glRotate

What's the problem then? Well, you never start at the origin, because there's always the VIEW transform that has been applied before getting to our flowerpot. If glLoadIdentity resets everything and we're at the origin (0, 0, 0), what's the new coordinate frame when you apply the view transform? It's something weird most of the time, isn't it? Now you have to worry about how to get from that coordinate frame to your flowerpot. Which is not something you need to do, you have to pretend that we're still at the origin, facing down the z-axis. With the reverse model on the other hand, there's no inconsistency, you always go from local to global to view.

Anyway, this is just wankery and I guess you can choose whatever works best for you. Personally the reverse thing helped me when I was getting started, because I was used to the local vs global transformations from 3D modelling apps (and OpenGL only has global really). Either way, it only becomes crystal clear when you work out the math.

The reference book isn't wrong and I insist on what I said about the reverse order.

That picture above from the book, is what you want to happen. For example, the get the result on the left, you have to first rotate and then translate. In order to achieve this in OpenGL, you have to do:

1) glTranslate
2) glRotate

i.e. in the reverse order. That's because, mathematically, the new transform in applied to the current matrix from the right side:

glLoadIdentity => I
glTranslate => I * T
glRotate => I * T * R

When you multiply this matrix with a vertex, you multiply from the left side:

I * T * R * v

Which results in what you want to achieve in the first place: T * (R * v), i.e. you first rotate and then translate.

The GL_VIEWPORT matrix is NOT the camera matrix. Some definitions first:

v: The vertex coordinates in local (model) space.
M: The model matrix. Transforms local coordinates to world coordinates.
V: The view matrix. Transforms world coordinates to eye coordinates.
P: The projection matrix. Transforms eye coordinates to clip coordinates.
VP: The viewport matrix. Transforms normalized device coordinates to window coordinates.

So, this is what happens conceptually:

v -> (transformed by M) -> world -> (transformed by V) -> eye -> (transformed by P) -> clip -> (divide by w) -> normalized device -> (transformed by VP) -> window coordinates.

What you care about in the vertex shader (or with the fixed-function transformations) is the first 3 transforms. Mathematically, this is what actually happens:

clip space vertex = P * (V * (M * v))

This is the vertex shader output. But it's 3 matrix-vector multiplications so, for performance reasons, in practice what we actually use is the ModelViewProjection matrix, or the MVP:

MVP = P * (V * M)

so, clip space vertex = MVP * v

Now, we're free to do the above however we like in a vertex shader, but with fixed-function OpenGL there are fixed mappings to the above concepts:

VP = GL_VIEWPORT
P = GL_PROJECTION
MV = GL_MODELVIEW (there's no M or V!)
MVP = calculated on the fly, you don't have to worry about it

VP and P are simple, you set them usually once when you load your scene and don't have to change them again. But the MV matrix has to change per draw-call. How do you avoid having to set the camera transformation for each one of your models? It's easy, because of how the gl<Transform> calls work. If you do a glTranslatef followed by a glRotatef, what actually happens is that the vertex is first rotated and then translated, i.e., in the opposite order of the transformation calls you made. So, all you have to do is:



The above code ensures that the M matrix will always be applied before the V matrix, for all your models.

Bitbucket is also nice (similar to github) and you can have private repos for free if your team is up to 5 people.

Indeed, for example this is what Kotlin lets you do. The benefit is that you never encounter unpleasant surprises at runtime. The IDE also highlights variables within inner scopes that have been auto-casted to another type.

Because it's not really type inference. The compiler just lets you omit information that's already there.

Real type inference would require extensive code analysis at compile time, which would slow down javac. Imagine a condition or loop before the assignment to blah that assigns something other than a String to s. Also, it wouldn't offer much benefit without a new val/var keyword (or C++11's auto).

No, e is an ActionEvent, the argument of the actionPerformed method of ActionListener. The lambda expression makes the method itself and the inner class instantiation go away.

Btw, lambdas allow an explicit type, so you could write it as:


This is a good example of a language feature that allows you to be more explicit and less dense if you wish so. The problem (imho) is when you can't do the opposite.


Indeed, it compiles down to indy in the current JDK 8 builds. I should have said that, at runtime, it compiles down to the same-thing in the worst case scenario (if the JVM can't use a method handle and creates an instance instead).