Why is AWTGLCanvas so much faster than the native Display?

[Qudus]

btw. I guess, the display_impl.update() call can be simply removed from the isCloseRequested() method, since it will assumably never be queried without another call (like Display.update()) calling the display_impl.update() once before. If this can not be said for sure, just overload it as well with a boolean parameter. Currently the isCloseRequested() method is unnecessarily expensive, which lead me to just calling it each 10ms, which is quick hackish, but did a noticeable speedup.

Hmm... I don't want to be a pain in the ass. Sorry, if I am. But I didn't get an answer to this questions.

Marvin

[elias]

Sorry, but I don't like the overloaded boolean method and I'm not convinced isCloseRequested() won't be called without Display.update() first. Consider

if (Display.isVisible()) {
    Display.update();
}
if (Display.isCloseRequested())
    System.exit(0);

- elias

[Qudus]

Well, in this code the display_impl.update() method would be called three times. Once by the isVisible() method, once by the update() method and once by isCloseRequested(). No matter in which order. Or am I wrong?

And if you like the overloaded approach or not. You must admit, that taking 2% of the entire performance of an expensive testcase just for querying the is-close-requested state cannot be accepted. Don't you agree? Just have a socond look at my timing results of the Gears test, where isCloseRequested() even took 60%.

Marvin

[elias]

With the newest lwjgl, will it still be 2%?

  - elias

[Qudus]

With the newest lwjgl, will it still be 2%?

Well, since you didn't remove the display_impl.update() method from the isCloseRequested() method, it should be. I guess, it would be best, if you would test it with the Gears Test and compare it (percentually) with my results above.

Marvin

[Matzon]

Nightly builds are not really practical, since we need access to all three platforms to build the natives. However, with a little luck, Mazon will release 1.1.4 tonight

That would be awesome . Thanks.

Marvin

meh - I decided to play some Enemy Territory instead 
Tomorrow!

[Qudus]

meh - I decided to play some Enemy Territory instead 
Tomorrow!

No problem. Have fun .

Marvin

[elias]

We've more or less some to the conclusion that there changes should be done as part of a lwjgl 2.0, so we're going to release 1.1.4 without any (intentional) breakage and see if we can get a 2.0 out with all the controversial changes (most likely your changes and the replacement of devil and fmod).

- elias

[Qudus]

ok

But I have a new idea, how you could simply use caching to improve the performance without changing anything in the API.

The LinuxDisplay and WindowsDisplay would simply need to store a frame-ID (long). The swapBuffers() method would then increase the frame-ID stored in Display and any call to display_impl.update() would pass the current Display's frame-ID to the impl. Then the display_impl.update() method would immediately return, if the incoming frame-ID is not greater than the currently stored one. If it is greater, it is stored.

Wouldn't this be easy to implement and very convenient?

Marvin

[elias]

I thought about a similar solution, too (which would need to be implemented for all queries in Display too). However, we have a bunch of even more intrusive changes lined up for 2.0, so I won't bother.

- elias