AWTGLCanvas and PixelFormat

Started by radvani, November 10, 2006, 00:41:59

Previous topic - Next topic

radvani

Hi everyone,

I'm developing an application using the AWTGLCanvas, and it's important that I be able to support a number of video cards. In other words, I need to determine what pixel format to use based on the specs of the video card. I noticed that in non-AWT applications, people call Display.create() with numerous pixel formats until they find one that works (i.e. one that doesn't throw an exception).

My question is: is there a way to do this with the AWTGLCanvas? That is, how can I test if a PixelFormat works when I'm not directly using the Display class?

Thanks very much!

Raj

cornholio

i have the same question. since org.lwjgl.opengl.AWTGLCanvas.paint(...) is final
the thrown RuntimeException can't be caught by overriding this method...

Fool Running

It does seem that it would be a good idea to be able to catch that exception and/or be able to override the method. Any devs have a comment on this?
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

Evil-Devil

YOu could try to create a PBuffer with the specific PixelFormat and test it through it.

Fool Running

QuoteYOu could try to create a PBuffer with the specific PixelFormat and test it through it.
Is it possible that a PBuffer can successfully get created with a PixelFormat that would fail in Display.create()? If not, than that would work, but I would assume that it would be possible. (I could be wrong ;D )
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

Evil-Devil

Quote from: Fool Running on January 02, 2007, 22:01:07
QuoteYOu could try to create a PBuffer with the specific PixelFormat and test it through it.
Is it possible that a PBuffer can successfully get created with a PixelFormat that would fail in Display.create()?
AFAIK PBuffer and Display have the same abilities.

elias

This is a reasonable request, so I've added an exceptionOccurred method that can be overridden to be notified of unhandled LWJGLExceptions:

    /**
     * This method will be called if an unhandled LWJGLException occurs in paint().
     * Override this method to be notified of this.
     *
     * @param exception The exception that occurred.
     */
    protected void exceptionOccurred(LWJGLException exception)


The default implementation simply logs the exception.

- elias

darkprophet

As an alternative to elias's method, you could implement Thread.UncaughtExceptionHandler then :

Thread.currentThread().setUncaughtExceptionHandler(new MyHandler());


This applies to not only LWJGLExceptions, but to all exceptions that get thrown while this thread is working. I would suggest you put this in initGL() as the thread that is calling initGL() is the same thread that calls paintGL()

Very useful for debugging and log tracing IMO.

Edit: Forgot to mention that this is a 1.5+ feature only. If you are targetting 1.4 you cant use it

HTH, DP

the2bears

Quote from: darkprophet on January 03, 2007, 12:50:01
As an alternative to elias's method, you could implement Thread.UncaughtExceptionHandler then :

Thread.currentThread().setUncaughtExceptionHandler(new MyHandler());


This applies to not only LWJGLExceptions, but to all exceptions that get thrown while this thread is working. I would suggest you put this in initGL() as the thread that is calling initGL() is the same thread that calls paintGL()

Very useful for debugging and log tracing IMO.

Edit: Forgot to mention that this is a 1.5+ feature only. If you are targetting 1.4 you cant use it

HTH, DP

Well, you sort of can if you put the thread in a ThreadGroup, as this much (rightly!) maligned class does have public void uncaughtException(Thread t, Throwable e).  The only thing I ever used it for.

Bill
the2bears - the indie shmup blog

cornholio

Quote from: elias on January 03, 2007, 09:16:34
I've added an exceptionOccurred method that can be overridden to be notified of
unhandled LWJGLExceptions. The default implementation simply logs the exception.

a very elegant solution, indeed. it does not break existing applications and
provides a neat way to handle unsupported pixelformats and similar problems.

up to now i used to put my threads in a ThreadGroup as described by the2bears
since it is the only reliable way to determine the unexpected death of a thread in
a pre-1.5 environment.

thanks to the new method i can throw out that cumbersome crap and go with the
much cleaner solution of overriding exceptionOccurred(LWJGLException exception)

big thanks to elias for the quick response and all the great work - LWJGL rocks !