slow Drawing when switching to nightly build

OpenGL Development JOGL Development
#1

Hello all, sorry but I’m new to jogl and I have not found some good Introduction into jogl (is there anywhere something?) so I tried some samples.

First I’ve downloaded the win32 stuff from the Release 2003 folder and it work’s fine, but when I switch to the ‘nightly binary build’ version I can see on the screen how every line (I use a vertex buffer) is drawn, seem’s to me that there is no hardware acceleration, suddenly, because the older version runs well and fast.

Maybe I used the wrong jar file on windows XP, but I’m a litte bit confused about the many different jar files.

The second thing I’,looking for is, How to create a doubleBuffered canvas and control the the swapping with a function like SwapBuffers(), but I did not find how to do it.

I know that creating doubleBuffered windows and swapping them is platform dependent (If you make OpenGL with C, C++ or something else) but I hope jogl has a swapbuffer function and the platform dependend stuff is done in the native libraries.

thanks for any tips…

#2

What platform, graphics card, and drivers?

#3

Its a notebook with Windows XP Professional SP1, built in Intel 82852/82855 GM/GME Graphics Controller and Driver Version 4.14.10.3691.

But what depends on this? The 2003 stable version works well and fast…

Thanks

#4

I also just upgraded to 1.1 b02 and the quality and speed went way down. I’m getting a lot of flickering between each redraw. I’m also using the Win32 libraries from 1.1 b01 (as the b02 were not available yet??). I’m using an Animator to redraw each frame. Has something changed that I need to reflect in my GLCanvas setup perhaps?

Win2k, ATI Radeon 7000 - 32Mb, latest SDK and JRE.

#5

The major thing that changed is the pixel format selection algorithm – it now uses the underlying window system’s recommended choice for pixel format rather than attempting to use a cross-platform algorithm. Unfortunately it sounds like some people are seeing very bad choices coming back from either ChoosePixelFormat or wglChoosePixelFormatARB. Do you have a test program illustrating the problem?

#6

[quote]… Do you have a test program illustrating the problem?
[/quote]
Sure… any of the latest Demo programs. I’ll try and see if I can force a pixel format, and see if that makes any difference.

#7

Hi,

[quote]Unfortunately it sounds like some people are seeing very bad choices coming back from either ChoosePixelFormat or wglChoosePixelFormatARB.
[/quote]
Yes, that’s true.

New selection algorithm was failing for me on Toshiba Satellite S5100-503 with NVidia GeForce4 440 Go, 1600x1200 32bpp and drivers version 2846 (latest available from Toshiba, not possible to use drivers from NVidia because of it is Go card).

New selection returned a mode with Microsoft’s implementation of OpenGL (reported Microsoft renderer and OGL version 1.1)

To make it working again I had to fall back to old implementation of DefaultGLCapabilitiesChooser and provide it with Xith3D.

Ken, if you want me to do more testing, let me know. We use JOGL for commercial projects and interested in stability/compatibility very much.

Yuri

#8

[quote]Ken, if you want me to do more testing, let me know. We use JOGL for commercial projects and interested in stability/compatibility very much.
[/quote]
I would appreciate your help. Do you happen to know which code path WindowsGLContext.choosePixelFormatAndCreateContext() went down, the wglChoosePixelFormatARB arm or the ChoosePixelFormat arm? Could you put in a println()?

If it turns out that ChoosePixelFormat is just returning bad pixel formats then maybe we can just eliminate that arm and fall back on the existing DefaultGLCapabilitiesChooser if wglChoosePixelFormatARB isn’t available. On the other hand, if wglChoosePixelFormatARB is choosing an unaccelerated pixel format (which it shouldn’t be), we may have to add more code to filter out bad choices…

#9

wglChoosePixelFormat seems to be very strict. If I request a 32bit depth buffer on my nvidia card it won’t return any valid pixel formats because nvidia hardware only supports 24bit depth buffers.


wglChoosePixelFormatARB selects pixel formats to return based on the
    attribute values specified in <piAttribIList> and <pfAttribFList>.
    Some attribute values must match the pixel format value exactly when
    the attribute is specified while others specify a minimum criteria,
    meaning that the pixel format value must meet or exceed the
    specified value. See the table below for details.


     Attribute                      Type      Match Criteria

     WGL_DRAW_TO_WINDOW_ARB          boolean      exact
     WGL_DRAW_TO_BITMAP_ARB          boolean      exact
     WGL_ACCELERATION_ARB          enum      exact
     WGL_NEED_PALETTE_ARB          boolean      exact
     WGL_NEED_SYSTEM_PALETTE_ARB    boolean      exact
     WGL_SWAP_LAYER_BUFFERS_ARB     boolean      exact
     WGL_SWAP_METHOD_ARB          enum      exact
     WGL_NUMBER_OVERLAYS_ARB          integer      minimum
     WGL_NUMBER_UNDERLAYS_ARB          integer      minimum
     WGL_SHARE_DEPTH_ARB          boolean      exact
     WGL_SHARE_STENCIL_ARB          boolean      exact
     WGL_SHARE_ACCUM_ARB          boolean      exact
     WGL_SUPPORT_GDI_ARB          boolean      exact
     WGL_SUPPORT_OPENGL_ARB          boolean      exact
     WGL_DOUBLE_BUFFER_ARB          boolean      exact
     WGL_STEREO_ARB                boolean      exact
     WGL_PIXEL_TYPE_ARB                enum      exact
     WGL_COLOR_BITS_ARB                integer      minimum
     WGL_RED_BITS_ARB                integer      minimum
     WGL_GREEN_BITS_ARB                integer      minimum
     WGL_BLUE_BITS_ARB                integer      minimum
     WGL_ALPHA_BITS_ARB                integer      minimum
     WGL_ACCUM_BITS_ARB                integer      minimum
     WGL_ACCUM_RED_BITS_ARB          integer      minimum
     WGL_ACCUM_GREEN_BITS_ARB          integer      minimum
     WGL_ACCUM_BLUE_BITS_ARB          integer      minimum
     WGL_ACCUM_ALPHA_BITS_ARB          integer      minimum
     WGL_DEPTH_BITS_ARB                integer      minimum
     WGL_STENCIL_BITS_ARB          integer      minimum
     WGL_AUX_BUFFERS_ARB          integer      minimum
#10

Yes, wglChoosePixelFormatARB and glXChoosePixelFormat share the same strict pixel format selection behavior. Personally I prefer a less strict algorithm, but until recently we haven’t had the ability to get enough information about pixel formats on Windows to be able to identify which pixel formats work for which situations (render to onscreen window vs. render to pixmap vs. render to pbuffer), meaning that we have to rely on ChoosePixelFormat / wglChoosePixelFormatARB in some situations instead of being able to use a pure-Java, cross-platform algorithm. I haven’t looked into all of the rules on X11 either. Maybe we can use glXGetFBConfigs / glXGetFBConfigAttrib to implement visual selection for pbuffers, which I think is the remaining case which isn’t implemented with the GLCapabilitiesChooser.