LWJGL Forum

Programming => Lightweight Java Gaming Library => Topic started by: benomatic42 on March 11, 2010, 22:22:20

Title: gears applet - thread startLWJGL vs. Applet.start()
Post by: benomatic42 on March 11, 2010, 22:22:20
When working from the org/lwjgl/test/applet/GearsApplet.java as an example, I noticed that Canvas.{add,remove}Notify are overridden to provide thread start/stop, but that Applet.start/stop are empty:


    public void init() {
        setLayout(new BorderLayout());
        try {
            display_parent = new Canvas() {
                public final void addNotify() {
                    super.addNotify();
                    startLWJGL();
                }
                public final void removeNotify() {
                    stopLWJGL();
                    super.removeNotify();
                }
            };
            ...


Is there an order of execution thing going on here that makes .start/stop unsuitable (or too late)?  Or is there another reason that they are not used?

Note: I am a seasoned backend/system dev, but new to java+gui, so I apologize if this is rudimentary.

Thanks,

-b
Title: Re: gears applet - thread startLWJGL vs. Applet.start()
Post by: kappa on March 11, 2010, 22:30:14
yes its intentional.

start() and stop() are not suitable for destroying and creating lwjgl's Display as they can be called at any time depending on the browser and plugin version. Some browsers call start() and stop() on the applet if the browser is minimised/maximized.

Also the Canvas must exist for Display.setParent to work, so its a good safeguard against it unintentionally being destroyed and the LWJGL Display still existing while its parent is gone.