Hello Guest

Why is AWTGLCanvas so much faster than the native Display?

  • 39 Replies
  • 46850 Views
*

Offline Qudus

  • ***
  • 123
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #30 on: January 19, 2008, 17:16:44 »
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

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #31 on: January 19, 2008, 21:57:22 »
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

Code: [Select]
if (Display.isVisible()) {
    Display.update();
}
if (Display.isCloseRequested())
    System.exit(0);

 - elias

*

Offline Qudus

  • ***
  • 123
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #32 on: January 19, 2008, 22:44:17 »
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
« Last Edit: January 19, 2008, 22:48:11 by Qudus »

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #33 on: January 19, 2008, 22:47:08 »
With the newest lwjgl, will it still be 2%?

  - elias

*

Offline Qudus

  • ***
  • 123
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #34 on: January 19, 2008, 22:49:29 »
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

*

Offline Matzon

  • *****
  • 2242
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #35 on: January 19, 2008, 23:23:49 »
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! :)

*

Offline Qudus

  • ***
  • 123
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #36 on: January 19, 2008, 23:36:03 »
meh - I decided to play some Enemy Territory instead  ::)
Tomorrow! :)

No problem. Have fun ;).

Marvin

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #37 on: January 20, 2008, 11:10:55 »
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

*

Offline Qudus

  • ***
  • 123
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #38 on: January 20, 2008, 14:40:36 »
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

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Why is AWTGLCanvas so much faster than the native Display?
« Reply #39 on: January 20, 2008, 17:21:33 »
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