Hello Guest

[FIXED] Bug with nSetLayerPosition in Mac OS X

  • 1 Replies
[FIXED] Bug with nSetLayerPosition in Mac OS X
« on: August 26, 2013, 20:45:39 »
While working on my engine on a Mac 10.8.2, I noticed sporadic behavior where the parent canvas would slide to the bottom and left, and have its center located at the lower-left corner of its containing frame.  I assumed it was something funny with the threading I was doing in my engine, because the AWT components were manipulated on the EDT, but the Display was created on my own thread.  I tracked it down to the component resize event firing and calling nSetLayerPosition().  It seems that if this happens too early (for an unknown definition of too early), the nSetLayerPosition moves where the canvas is drawn to with respect to the frame.

Here is a small demo that reproduces this bug 100% of the time on my machine:
Code: [Select]
import org.lwjgl.LWJGLException;
import org.lwjgl.opengl.Display;

import java.awt.*;

public class CALayerTest {
    public static void main(String[] args) throws Exception {

        EventQueue.invokeAndWait(new Runnable() {
            public void run() {
                final Frame frame = new Frame();
                final Canvas canvas = new Canvas();

                frame.setBounds(0, 0, 500, 500);

                canvas.requestFocusInWindow(); // We use LWJGL's input system, but just in case


                try {
                } catch (LWJGLException e) {

In this case, I'm not mixing any threading, the parented display is created on the AWT thread.  Is this just wrong practice on my part? Even if I'm using the AWT parent should I stay off the EDT?  Maybe I'm just being too paranoid because of the explicit lack of thread-safety in Swing, but parts of AWT are thread-safe (on the other hand, plenty of component fields are not volatile and not guarded by locks, so....)

« Last Edit: October 26, 2013, 16:07:28 by kappa »


Offline kappa

  • *****
  • 1316
Re: Bug with nSetLayerPosition in Mac OS X
« Reply #1 on: October 26, 2013, 16:07:14 »
Thank for providing the test case which reproduced the issue, was most helpful.

This should now be fixed and will be available in the next nightly build of LWJGL.