Hello all. I have made a program that could run while dragging the window around using just pure java. But for some reason I am unable to do that with LWJGL3.
Here is the code. As you should be able to spot, it runs as normal. However, if I drag the window around my desktop, notice, it stops the program. Now with pure java you can do this. Repainting the screen even while dragging is very doable. But I am unable to "fix" this for LWJGL3.
Any ideas ? Here is the code I am currently working with as a test.
package main;
import static org.lwjgl.glfw.GLFW.*;
import static org.lwjgl.opengl.GL11.*;
import static org.lwjgl.system.MemoryUtil.*;
import java.nio.ByteBuffer;
import org.lwjgl.glfw.GLFWvidmode;
public class Main implements Runnable {
private int width = 800;
private int height = 600;
private Thread thread;
private boolean running = false;
private long window;
public void start() {
running = true;
thread = new Thread(this, "Test");
thread.start();
}
private void init() {
if(glfwInit() != GL_TRUE) {
// To Do Later
return;
}
glfwWindowHint(GLFW_RESIZABLE, GL_TRUE);
window = glfwCreateWindow(width, height, "Test", NULL, NULL);
if(window == NULL) {
// To Do Later
return;
}
ByteBuffer vidmode = glfwGetVideoMode(glfwGetPrimaryMonitor());
glfwSetWindowPos(window, (GLFWvidmode.width(vidmode) - width) / 2, (GLFWvidmode.height(vidmode) - height) / 2);
glfwMakeContextCurrent(window);
glfwShowWindow(window);
}
public void run() {
init();
while(running) {
update();
render();
if(glfwWindowShouldClose(window) == GL_TRUE) {
running = false;
}
}
}
private void update() {
glfwPollEvents();
System.out.println("This is rendering !!!!!");
}
private void render() {
glfwSwapBuffers(window);
}
public static void main(String[] args) {
new Main().start();
}
}
This is the first issue on the GLFW GitHub repo.
https://github.com/glfw/glfw/issues/1
Not only moving the window, but also resizing it will block the event loop, as was required by OSX (not sure, thinking so as found on a similar issue on openframeworks). This can simply be solved by setting a refresh callback. I will try to provide an example soon. Until then, see this commit: https://github.com/glfw/glfw/commit/cb11b7ca6f06195d361c74b8db71166f1a716047
Quote from: SHC on June 03, 2015, 06:25:06
This is the first issue on the GLFW GitHub repo.
https://github.com/glfw/glfw/issues/1
Not only moving the window, but also resizing it will block the event loop, as was required by OSX (not sure, thinking so as found on a similar issue on openframeworks). This can simply be solved by setting a refresh callback. I will try to provide an example soon. Until then, see this commit: https://github.com/glfw/glfw/commit/cb11b7ca6f06195d361c74b8db71166f1a716047
Well that's sad. MAC OSX can't do it so no OS will be able to do it. Something about that logic just doesn't seem right. LOL
This issue exists on Windows and Linux too. If the event loop and rendering run on the same thread, blocking in the event loop will freeze rendering.
Quote from: SHC on June 03, 2015, 06:25:06
This can simply be solved by setting a refresh callback. I will try to provide an example soon. Until then, see this commit: https://github.com/glfw/glfw/commit/cb11b7ca6f06195d361c74b8db71166f1a716047
I was examining the COMMIT you suggested and I see this.. with an asterisk. I am not sure how to convert that to Java since that is a pointer and Java doesn't use pointers.
static void windowRefreshFun(GLFWwindow* window)
I'll just wait for your example code. Use my OP code so you don't have to write so much. ;)
@ SHC
Hey there, well apparently my PMs do not reach you so I am asking here. You ever get around to making that example of the refresh screen while dragging the window around ? Wasn't sure if you forgot me. ;)
Just to let you know, I tried to make a class like this to invoke it.. but it didn't work.
public class RefreshCallback extends GLFWWindowRefreshCallback {
public void invoke(long window) {
System.out.println("Testing !!");
}
}
Your PMs did reach me, but I needed some time to work on my personal works (college is starting again in a few weeks), and I did get this working. All you need is two additional callbacks, glfwRefreshFun and glfwWindowSizeFun, and just trigger a render from those callbacks and swap the buffers.
https://github.com/sriharshachilakapati/SilenceEngine/blob/master/src/main/java/com/shc/silenceengine/tests/GLFWTest.java
I'm sorry, I used my OOP GLFW wrapper here, but I think you get the idea. Will convert that to a plain LWJGL example soon when I have got time.
Quote from: SHC on June 08, 2015, 14:00:10
Your PMs did reach me, but I needed some time to work on my personal works (college is starting again in a few weeks), and I did get this working. All you need is two additional callbacks, glfwRefreshFun and glfwWindowSizeFun, and just trigger a render from those callbacks and swap the buffers.
https://github.com/sriharshachilakapati/SilenceEngine/blob/master/src/main/java/com/shc/silenceengine/tests/GLFWTest.java
I'm sorry, I used my OOP GLFW wrapper here, but I think you get the idea. Will convert that to a plain LWJGL example soon when I have got time.
I just tested out your engine. Nice work. I tested all your test java samples in your test package. Love the text. None of the examples allowed the window to continue "painting" while dragging window around though. So I am still confused about it. I might just have to give up on the idea.
But I wanted to say thanks for sharing the engine. Great stuff.
I don't know why it didn't work for you, the GLFWTest should re-paint while moving and resizing the window. Here's a crappy GIF showing that it's working.
(http://i.imgur.com/7ojkoZG.gif)
Other tests do not use this behaviour, it is disabled by default in the engine. You can enable it manually by setting the callbacks to the display window manually. Thanks for your compliment BTW.
@JackDawson, you are right. GLFW does not allow you to render when you are moving (or just keeping a hold of the window's title bar when holding the left mouse button on it).
If you have an animated scene (which a static triangle is not) you recognize this.
@SHC: With a static triangle it just "seems" that it is rendering when you move the window, when in fact all you see there is the back-buffered image, which was rendered before you moved the window. Use an animated render to see what JackDawson and I mean.
Quote from: Kai on June 13, 2015, 09:54:40
@JackDawson, you are right. GLFW does not allow you to render when you are moving (or just keeping a hold of the window's title bar when holding the left mouse button on it).
If you have an animated scene (which a static triangle is not) you recognize this.
@SHC: With a static triangle it just "seems" that it is rendering when you move the window, when in fact all you see there is the back-buffered image, which was rendered before you moved the window. Use an animated render to see what JackDawson and I mean.
@SHC
I can render a non animated scene all day long. But animated with move or resize of the screen and the screen freezes the animation. And then you let go of the mouse, the animation speeds up really fast to catch up. Try it with your movable blocks and then try to move and you will see the behavior I am speaking about.
@Kai
Exactly what I mean. Thank you for understanding. I been wracking my brain for weeks over this. A lot of posts I have read, JOGL can do it, but as you and many others have said, GLFW / LWJGL can not. I really hope this function gets added.
This guy shows it working but he obviously is not using LWJGL or JOGL. Just pure C++ and OpenGL.
http://www.songho.ca/opengl/gl_mvc.html
Scroll down to the planet scene. He has full source code and the bin files to show it works. The earth keeps spinning even while you drag the screen around. I am hoping that by showing this one of you might figure out how its done and add the functionality to LWJGL. I am a newbie when it comes to C++. So I am unable to figure this out.
On another note : Pure straight Java can do this. I have written a pure java code that animated and it would continue to do so while you drag it around. So I know Java can do it.
Turns out GLFW DOES allow you to do this! All GLFW wants is that the window proc runs in the main thread. But this restriction does not apply to the OpenGL render context.
So I just did a small example which handles window proc in the main thread that also creates the GLFW window, and then makes the OpenGL context current and does the rendering in another spawned thread!
This works (at least under Windows 7).
I modified this joml-lwjgl3-demo (https://github.com/JOML-CI/joml-lwjgl3-demos/blob/master/src/org/joml/lwjgl/ShaderExample.java) to make use of this.
Use this simpler demo (https://github.com/LWJGL/lwjgl3-demos/blob/master/src/org/lwjgl/demo/opengl/glfw/Multithreaded.java) instead.
Quote from: Kai on June 13, 2015, 10:29:04
Turns out GLFW DOES allow you to do this! All GLFW wants is that the window proc runs in the main thread. But this restriction does not apply to the OpenGL render context.
So I just did a small example which handles window proc in the main thread that also creates the GLFW window, and then makes the OpenGL context current and does the rendering in another spawned thread!
This works (at least under Windows 7).
I modified this joml-lwjgl3-demo (https://github.com/JOML-CI/joml-lwjgl3-demos/blob/master/src/org/joml/lwjgl/ShaderExample.java) to make use of this.
Awesome. I will look at your code and check it out. Thank you !!
I did a dead simple demo not requiring shaders and/or JOML: Here it is (https://github.com/LWJGL/lwjgl3-demos/blob/master/src/org/lwjgl/demo/opengl/glfw/Multithreaded.java)
EDIT: Now that we use separate threads, we can better use glfwWaitEvents() instead of glfwPollEvents(). The former blocks until an event can be processed and therefore does not keep that loop so busy anymore. :)
BOTH Demos worked Perfectly !!!!!!!! ;D
THANK YOU THANK YOU THANK YOU !!!!!!
My day just got soooo much brighter. Now its been proven that it can work and with LWJGL3. OMG I am doing the happy dance !! hahaha..
You guys rock !! I appreciate all this help. Finally this thread can be marked as SOLVED.
@ Kai
So I am understanding how this works.. in your simpler demo...
Am I to understand that its the FrameBufferSizeCallback that is triggered when it recognizes that its no longer animating ?
glfwSetFramebufferSizeCallback(window, fsCallback = new GLFWFramebufferSizeCallback() {}
And thus when it does recognize that the frames have stopped showing, it triggers that method to over rule the original thread ? or is it on the same thread, just simply replacing the original frame with an updated callback buffer ? MY guess is the buffer ends in 0 and so it triggers the Operating System to return a message to GLFW and thus it tells it "Hey I am not receiving anything" and so the FrameBufferSize method overrules the original frame.
Hm... a general "no" to all your questions and assumptions. :)
Let me explain:
That framebuffer size callback is triggered by GLFW (inside of glfwPollEvents() or glfwWaitEvents()) whenever the window manager (part of the operating system) notified the process/application that the window size and thus the framebuffer size has changed (GLFW just calls the "client area" of the window "framebuffer" and reports the client rect size). This usually happens when you resize the window via the mouse (maybe it is also triggered when resizing the window per Win32 API call, I don't know about that).
But to explain further, how that demo works:
There are two threads involved:
- the main thread which reads and interprets window events (via glfwPollEvents() or glfwWaitEvents()). On windows there is a message queue for that process, which gets messages from the operating system (the window manager) when something happens, such as resizing the window. Upon calling glfwPollEvents() or glfwWaitEvents() GLFW processes the messages in the message queue and then the various glfw callbacks get called on specific window messages. Such as when you entered a key on your keyboard, then there would be a "key input message" in the message queue, which gets then read by GLFW within glfwPollEvents() and upon that, the keyboard callback would get executed (if you have one registered!)
This is all the main thread does now: read and interpret window messages and invoke corresponding callbacks in Java
- the render thread: This thread executes OpenGL commands and renders to the window's back buffer and swaps buffers between the back and front buffers to make the render results visible. This thread owns the OpenGL context (which only a single thread can own at a given time, because OpenGL IS NOT multithreaded).
The "animation" in that demo is just done by rotating that quad based on the time elapsed since the last loop iteration, which is queried via System.nanoTime() and scaled to seconds. Therefore it looks like the quad is rotating smoothly.
Quote from: Kai on June 13, 2015, 11:37:57
Hm... a general "no" to all your questions and assumptions. :)
Let me explain:
That framebuffer size callback is triggered by GLFW (inside of glfwPollEvents() or glfwWaitEvents()) whenever the window manager (part of the operating system) notified the process/application that the window size and thus the framebuffer size has changed. This usually happens when you resize the window via the mouse (maybe it is also triggered when resizing the window per Win32 API call, I don't know about that).
But to explain further, how that demo works:
There are two threads involved:
- the main thread which reads and interprets window events (via glfwPollEvents() or glfwWaitEvents()). On windows there is a message queue for each window that gets messages from the operating system (the window manager) when something happens, such as resizing the window. Upon calling glfwPollEvents() or glfwWaitEvents() GLFW processes the messages in the message queue and then the various glfw callbacks get called on specific window messages. Such as when you entered a key on your keyboard, then there would be a "key input message" in the message queue, which gets then read by GLFW within glfwPollEvents() and upon that, the keyboard callback would get executed (if you have one registered!)
This is all the main thread does now: read and interpret window messages and invoke corresponding callbacks in Java
- the render thread: This thread executes OpenGL commands and renders to the window's back buffer and swaps buffers between the back and front buffers to make the render results visible. This thread owns the OpenGL context (which only a single thread can own at a given time, because OpenGL IS NOT multithreaded).
The "animation" in that demo is just done by rotating that quad based on the time elapsed since the last loop iteration, which is queried via System.nanoTime() and scaled to seconds. Therefore it looks like the quad is rotating smoothly.
Interesting and I can use a SYNC command to sync it down to say 60 frames a second in GLFW if I remember right. I will have to play with this new toy. Thank you for this info. I will definitely have to study up on how this works.
Also, I am assuming this works on all Operating Systems.
The syncing is done by glfwSwapBuffers() when you also made use of glfwSwapInterval() with a value greater than 0, which then will make use of V-Sync depending on the monitor's refresh rate.
Quote from: Kai on June 13, 2015, 11:45:56
The syncing is done by glfwSwapBuffers() when you also made use of glfwSwapInterval() with a value greater than 0, which then will make use of V-Sync depending on the monitor's refresh rate.
Gotya. Ok thank you once again. :)
@ Kai
I am getting error logs. The program "appears" to be running right. But I have been seeing this since the last updated demo you posted...
LOG
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x0000000000570010, pid=2580, tid=2272
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000570010
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00000000201a1800): JavaThread "Thread-0" [_thread_in_native, id=2272, stack(0x0000000023be0000,0x0000000023ce0000)]
siginfo: ExceptionCode=0xc000001d
Registers:
RAX=0x000007feea2a6ae0, RBX=0x0000000000010001, RCX=0x0000000000010001, RDX=0x000007feea2a6ae0
RSP=0x0000000023cdd0a8, RBP=0x0000000023cdf180, RSI=0x000000001e0c9f28, RDI=0x0000000000000108
R8 =0x0000000000570010, R9 =0x0000000755592038, R10=0x000007feea251600, R11=0x000000000281b0a0
R12=0x0000000000000000, R13=0x0000000023cdf210, R14=0x0000000023cdf170, R15=0x00000000201a1800
RIP=0x0000000000570010, EFLAGS=0x0000000000010202
Top of Stack: (sp=0x0000000023cdd0a8)
0x0000000023cdd0a8: 000007feea282dad 0000000023cddce0
0x0000000023cdd0b8: 0000000069616041 000000001dc74340
0x0000000023cdd0c8: 00000007c0070418 000000001dc71648
0x0000000023cdd0d8: 00000000000003d8 0000000020048680
0x0000000023cdd0e8: 0000000002064ad0 0000000000000000
0x0000000023cdd0f8: 00000007c0025188 000000000203d540
0x0000000023cdd108: 000000006971f95e 00000000201a1800
0x0000000023cdd118: 0000000069554eb5 0000000023cdd160
0x0000000023cdd128: 0000000023cdd1c0 00000000201a1800
0x0000000023cdd138: 000000001dc717c8 000000001dc71448
0x0000000023cdd148: 00000000695db5ec 0000000023cddd80
0x0000000023cdd158: 0000000023cdd200 000000001e0c9930
0x0000000023cdd168: 00000000201a1800 000000001da2dc88
0x0000000023cdd178: 000000006962b19f 00000000201a1800
0x0000000023cdd188: 0000000002064ad0 000000001da2dc88
0x0000000023cdd198: 00000000201a1800 000000001e0c9970
Instructions: (pc=0x0000000000570010)
0x000000000056fff0:
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xc0000005]
Register to memory mapping:
RAX=0x000007feea2a6ae0 is an unknown value
RBX=0x0000000000010001 is an unknown value
RCX=0x0000000000010001 is an unknown value
RDX=0x000007feea2a6ae0 is an unknown value
RSP=0x0000000023cdd0a8 is pointing into the stack for thread: 0x00000000201a1800
RBP=0x0000000023cdf180 is pointing into the stack for thread: 0x00000000201a1800
RSI=0x000000001e0c9f28 is pointing into metadata
RDI=0x0000000000000108 is an unknown value
R8 =0x0000000000570010 is an unknown value
R9 =0x0000000755592038 is an oop
java.io.PrintStream
- klass: 'java/io/PrintStream'
R10=0x000007feea251600 is an unknown value
R11=0x000000000281b0a0 is at entry_point+0 in (nmethod*)0x000000000281af10
R12=0x0000000000000000 is an unknown value
R13=0x0000000023cdf210 is pointing into the stack for thread: 0x00000000201a1800
R14=0x0000000023cdf170 is pointing into the stack for thread: 0x00000000201a1800
R15=0x00000000201a1800 is a thread
Stack: [0x0000000023be0000,0x0000000023ce0000], sp=0x0000000023cdd0a8, free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x0000000000570010
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 317 org.lwjgl.glfw.GLFW.nglfwWindowShouldClose(J)I (0 bytes) @ 0x0000000002815841 [0x0000000002815800+0x41]
J 316 C1 org.lwjgl.glfw.GLFW.glfwWindowShouldClose(J)I (16 bytes) @ 0x000000000281b194 [0x000000000281b0a0+0xf4]
j Main.renderLoop()V+181
j Main$3.run()V+4
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x000000000211d800 JavaThread "DestroyJavaVM" [_thread_blocked, id=1392, stack(0x0000000002150000,0x0000000002250000)]
=>0x00000000201a1800 JavaThread "Thread-0" [_thread_in_native, id=2272, stack(0x0000000023be0000,0x0000000023ce0000)]
0x0000000020043800 JavaThread "Service Thread" daemon [_thread_blocked, id=3116, stack(0x0000000020430000,0x0000000020530000)]
0x000000001e39a800 JavaThread "C1 CompilerThread2" daemon [_thread_blocked, id=1356, stack(0x000000001ff10000,0x0000000020010000)]
0x000000001e398800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=3572, stack(0x000000001fdc0000,0x000000001fec0000)]
0x000000001e392800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=1872, stack(0x000000001fb10000,0x000000001fc10000)]
0x000000001e391000 JavaThread "Attach Listener" daemon [_thread_blocked, id=2100, stack(0x000000001f9d0000,0x000000001fad0000)]
0x000000001e38d800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=1196, stack(0x000000001f660000,0x000000001f760000)]
0x000000001e330800 JavaThread "Finalizer" daemon [_thread_blocked, id=2672, stack(0x000000001f810000,0x000000001f910000)]
0x000000001e32f800 JavaThread "Reference Handler" daemon [_thread_blocked, id=1420, stack(0x000000001f540000,0x000000001f640000)]
Other Threads:
0x000000001e32a000 VMThread [stack: 0x000000001f420000,0x000000001f520000] [id=4068]
0x0000000020047800 WatcherThread [stack: 0x000000001fcb0000,0x000000001fdb0000] [id=2948]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap:
PSYoungGen total 95744K, used 16527K [0x0000000755580000, 0x000000075c000000, 0x00000007c0000000)
eden space 82432K, 20% used [0x0000000755580000,0x00000007565a3c08,0x000000075a600000)
from space 13312K, 0% used [0x000000075b300000,0x000000075b300000,0x000000075c000000)
to space 13312K, 0% used [0x000000075a600000,0x000000075a600000,0x000000075b300000)
ParOldGen total 218624K, used 0K [0x0000000680000000, 0x000000068d580000, 0x0000000755580000)
object space 218624K, 0% used [0x0000000680000000,0x0000000680000000,0x000000068d580000)
Metaspace used 6643K, capacity 7928K, committed 8064K, reserved 1056768K
class space used 505K, capacity 552K, committed 640K, reserved 1048576K
Card table byte_map: [0x0000000011a00000,0x0000000012410000] byte_map_base: 0x000000000e600000
Marking Bits: (ParMarkBitMap*) 0x0000000069d24040
Begin Bits: [0x0000000012fa0000, 0x0000000017fa0000)
End Bits: [0x0000000017fa0000, 0x000000001cfa0000)
Polling page: 0x0000000000120000
CodeCache: size=245760Kb used=1948Kb max_used=1948Kb free=243811Kb
bounds [0x0000000002640000, 0x00000000028b0000, 0x0000000011640000]
total_blobs=877 nmethods=340 adapters=451
compilation: enabled
Compilation events (10 events):
Event: 2.781 Thread 0x000000001e39a800 335 ! 3 java.nio.CharBuffer::wrap (20 bytes)
Event: 2.781 Thread 0x000000001e39a800 nmethod 335 0x0000000002824d90 code [0x0000000002824f20, 0x00000000028252f8]
Event: 2.781 Thread 0x000000001e39a800 336 3 java.nio.HeapCharBuffer::<init> (14 bytes)
Event: 2.781 Thread 0x000000001e39a800 nmethod 336 0x0000000002825590 code [0x0000000002825700, 0x0000000002825948]
Event: 2.797 Thread 0x000000001e39a800 337 3 org.lwjgl.opengl.GL11::glMatrixMode (24 bytes)
Event: 2.798 Thread 0x000000001e39a800 nmethod 337 0x0000000002825a90 code [0x0000000002825c60, 0x00000000028262d8]
Event: 2.814 Thread 0x000000001e39a800 340 ! 3 java.io.BufferedWriter::write (117 bytes)
Event: 2.815 Thread 0x000000001e39a800 nmethod 340 0x0000000002826a10 code [0x0000000002826be0, 0x0000000002827308]
Event: 2.815 Thread 0x000000001e39a800 339 3 java.io.Writer::write (11 bytes)
Event: 2.815 Thread 0x000000001e39a800 nmethod 339 0x0000000002827750 code [0x00000000028278c0, 0x0000000002827bc8]
GC Heap History (0 events):
No events
Deoptimization events (0 events):
No events
Internal exceptions (2 events):
Event: 0.099 Thread 0x000000000211d800 Exception <a 'java/lang/NoSuchMethodError': Method sun.misc.Unsafe.defineClass(Ljava/lang/String;[BII)Ljava/lang/Class; name or signature does not match> (0x000000075558cdc8) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u45\3457\hotspot\srËõâ)Ã,ÂAÃ,¹?
Event: 0.099 Thread 0x000000000211d800 Exception <a 'java/lang/NoSuchMethodError': Method sun.misc.Unsafe.prefetchRead(Ljava/lang/Object;J)V name or signature does not match> (0x000000075558d058) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u45\3457\hotspot\src\share\vm\prims\j
Events (10 events):
Event: 0.716 loading class org/lwjgl/opengl/WGLEXTSwapControl done
Event: 0.716 loading class org/lwjgl/opengl/WGLNVCopyImage
Event: 0.716 loading class org/lwjgl/opengl/WGLNVCopyImage done
Event: 0.717 loading class org/lwjgl/opengl/WGLNVDelayBeforeSwap
Event: 0.717 loading class org/lwjgl/opengl/WGLNVDelayBeforeSwap done
Event: 0.717 loading class org/lwjgl/opengl/WGLNVDXInterop
Event: 0.717 loading class org/lwjgl/opengl/WGLNVDXInterop done
Event: 0.718 loading class org/lwjgl/opengl/WGLNVGPUAffinity
Event: 0.718 loading class org/lwjgl/opengl/WGLNVGPUAffinity done
Event: 3.482 Thread 0x000000000211d800 Thread exited: 0x000000000211d800
Dynamic libraries:
0x000000013f020000 - 0x000000013f057000 C:\Program Files\Java\jre1.8.0_45\bin\javaw.exe
0x00000000772f0000 - 0x0000000077499000 C:\Windows\SYSTEM32\ntdll.dll
0x00000000771d0000 - 0x00000000772ef000 C:\Windows\system32\kernel32.dll
0x000007fefd300000 - 0x000007fefd36c000 C:\Windows\system32\KERNELBASE.dll
0x000007fefea30000 - 0x000007fefeb0b000 C:\Windows\system32\ADVAPI32.dll
0x000007fefe990000 - 0x000007fefea2f000 C:\Windows\system32\msvcrt.dll
0x000007fefef30000 - 0x000007fefef4f000 C:\Windows\SYSTEM32\sechost.dll
0x000007fefdad0000 - 0x000007fefdbfd000 C:\Windows\system32\RPCRT4.dll
0x00000000770d0000 - 0x00000000771ca000 C:\Windows\system32\USER32.dll
0x000007fefec40000 - 0x000007fefeca7000 C:\Windows\system32\GDI32.dll
0x000007fefef50000 - 0x000007fefef5e000 C:\Windows\system32\LPK.dll
0x000007fefef60000 - 0x000007feff029000 C:\Windows\system32\USP10.dll
0x000007fefbb00000 - 0x000007fefbcf4000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\COMCTL32.dll
0x000007fefd740000 - 0x000007fefd7b1000 C:\Windows\system32\SHLWAPI.dll
0x000007fefdaa0000 - 0x000007fefdace000 C:\Windows\system32\IMM32.DLL
0x000007fefeb10000 - 0x000007fefec19000 C:\Windows\system32\MSCTF.dll
0x0000000069360000 - 0x0000000069432000 C:\Program Files\Java\jre1.8.0_45\bin\msvcr100.dll
0x0000000069520000 - 0x0000000069da3000 C:\Program Files\Java\jre1.8.0_45\bin\server\jvm.dll
0x000007fef9e80000 - 0x000007fef9e89000 C:\Windows\system32\WSOCK32.dll
0x000007fefee40000 - 0x000007fefee8d000 C:\Windows\system32\WS2_32.dll
0x000007feff510000 - 0x000007feff518000 C:\Windows\system32\NSI.dll
0x000007fef8b50000 - 0x000007fef8b8b000 C:\Windows\system32\WINMM.dll
0x000007fefc190000 - 0x000007fefc19c000 C:\Windows\system32\VERSION.dll
0x00000000774c0000 - 0x00000000774c7000 C:\Windows\system32\PSAPI.DLL
0x000000006e550000 - 0x000000006e55f000 C:\Program Files\Java\jre1.8.0_45\bin\verify.dll
0x000000006d330000 - 0x000000006d359000 C:\Program Files\Java\jre1.8.0_45\bin\java.dll
0x000000006e530000 - 0x000000006e546000 C:\Program Files\Java\jre1.8.0_45\bin\zip.dll
0x000007fefdc00000 - 0x000007fefe989000 C:\Windows\system32\SHELL32.dll
0x000007feff030000 - 0x000007feff233000 C:\Windows\system32\ole32.dll
0x000007fefd0b0000 - 0x000007fefd0bf000 C:\Windows\system32\profapi.dll
0x000007feea250000 - 0x000007feea31d000 C:\Users\sky\Documents\Workspace\Libs\lwjgl\native\lwjgl.dll
0x000007fee97c0000 - 0x000007fee98dd000 C:\Windows\system32\OPENGL32.dll
0x000007fef7fe0000 - 0x000007fef800d000 C:\Windows\system32\GLU32.dll
0x000007fee96c0000 - 0x000007fee97b1000 C:\Windows\system32\DDRAW.dll
0x000007fefaea0000 - 0x000007fefaea8000 C:\Windows\system32\DCIMAN32.dll
0x000007fefd8c0000 - 0x000007fefda97000 C:\Windows\system32\SETUPAPI.dll
0x000007fefd3b0000 - 0x000007fefd3e6000 C:\Windows\system32\CFGMGR32.dll
0x000007feff520000 - 0x000007feff5f7000 C:\Windows\system32\OLEAUT32.dll
0x000007fefd430000 - 0x000007fefd44a000 C:\Windows\system32\DEVOBJ.dll
0x000007fefb2b0000 - 0x000007fefb2c8000 C:\Windows\system32\dwmapi.dll
0x000007fefb690000 - 0x000007fefb6e6000 C:\Windows\system32\uxtheme.dll
0x00000000669c0000 - 0x0000000068899000 C:\Windows\system32\nvoglv64.DLL
0x000007fefae80000 - 0x000007fefae91000 C:\Windows\system32\WTSAPI32.dll
0x000007fefd3f0000 - 0x000007fefd42b000 C:\Windows\system32\WINTRUST.dll
0x000007fefd0d0000 - 0x000007fefd23d000 C:\Windows\system32\CRYPT32.dll
0x000007fefd0a0000 - 0x000007fefd0af000 C:\Windows\system32\MSASN1.dll
0x000007fefb240000 - 0x000007fefb26d000 C:\Windows\system32\ntmarta.dll
0x000007fefd7c0000 - 0x000007fefd812000 C:\Windows\system32\WLDAP32.dll
0x000007fefcea0000 - 0x000007fefcedd000 C:\Windows\system32\WINSTA.dll
0x000007fefcee0000 - 0x000007fefceef000 C:\Windows\system32\CRYPTBASE.dll
0x000007fee8cc0000 - 0x000007fee8de5000 C:\Windows\system32\dbghelp.dll
VM Arguments:
jvm_args: -Djava.library.path=C:\Users\user\Documents\Workspace\Libs\lwjgl\native -Dfile.encoding=Cp1252
java_command: Main
java_class_path (initial): C:\Users\user\Documents\Workspace\Animated Draggable Demo 3\bin;C:\Users\user\Documents\Workspace\Libs\lwjgl\jar\lwjgl.jar
Launcher Type: SUN_STANDARD
Environment Variables:
PATH=C:/Program Files/Java/jre1.8.0_45/bin/server;C:/Program Files/Java/jre1.8.0_45/bin;C:/Program Files/Java/jre1.8.0_45/lib/amd64;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\eclipse;
USERNAME=user
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows 7 , 64 bit Build 7601 (6.1.7601.18869)
CPU:total 4 (4 cores per cpu, 2 threads per core) family 6 model 26 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht, tsc, tscinvbit, tscinv
Memory: 4k page, physical 20969000k(18358344k free), swap 21229308k(17886312k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.45-b02) for windows-amd64 JRE (1.8.0_45-b14), built on Apr 10 2015 10:34:15 by "java_re" with MS VC++ 10.0 (VS2010)
time: Sat Jun 13 07:11:12 2015
elapsed time: 3 seconds (0d 0h 0m 3s)
EDIT UPDATE : This is random. It is not happening all the time.
Try the latest/current version of the simple demo. We now of course have to synchronize the main thread and the render thread on important GLFW calls. :)
Quote from: Kai on June 13, 2015, 12:21:40
Try the latest/current version of the simple demo. We now of course have to synchronize the main thread and the render thread on important GLFW calls. :)
Thank you. So far so good. If I see anything further I'll let you know.
Also, i noticed on the timer you used 1E9f.. I am used to seeing that with 1000f .. I changed it to 1000f and I ended up seeing the cube spinning faster. Is that HEX you are using ? I converted it to decimal and it came to 489. Is there some info about this ? I am curious how you came up with this.
NOTE : When I changed it to 489f it doesn't quite work as your HEX does. So I am puzzled by this.
It's the scientific notation for one million billion (1 with 9 zeroes). Look up on "scientific notation".
It is a very useful method of representing very big or very small (near zero) numbers in a short format, which is better than decimal having to fill a lot of zeroes in it.
I divide by one million billion to convert from nanoseconds (1 millionth billionth of a second) to seconds.
EDIT: Hex values in Java are prefixed by 0x (zero and 'x' character)
Quote from: Kai on June 13, 2015, 12:31:45
It's the scientific notation for one million (1 with 9 zeroes). Look up on "scientific notation".
It is a very useful method of representing very big or very small (near zero) numbers in a short format, which is better than decimal having to fill a lot of zeroes in it.
OHHHHHHHHHHHHHHH Duhhh !!! I should have known that !!
Boy is my face red.. LOL
To give an update to this thread.
Sadly, I had to go back to LWJGL 2.9.3. The math is complete in that version where as JOML it is not complete and when I made a 3D Engine out of LWJGL3 it bogged down badly. The performance was really sad.
The same engine in 2.9.3 works fine without slowing down.
I will have to see if there is a way to have the refreshing of the screen while dragging in 2.9.3. Thank you once again for trying to help out with my issues.