Home » Project database » Core » The Open Toolkit library » Issues
ebeckers's picture

Application always run in windowed mode when using shared contexts

Posted Monday, 9 November, 2009 - 17:22 by ebeckers
Project:The Open Toolkit library
Version:1.0-beta-2
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
Description

If you create a new thread which uses shared context ( in my case it is reponsible for texture loading )
then the main GameWindow won't run in fullscreen mode anymore.
It always runs in windowed mode

see http://www.opentk.com/node/1336


Comments

the Fiddler's picture

#1

Posted Monday, 9 November, 2009 - 17:25 by the Fiddler
Version:all versions» 0.9.9-3
Status:open» confirmed

Thanks.

Debug output from previous thread:

Size: 2304
System:
    Linux
 
 
 
 
Initializing threaded X11: 1.
Display connection: 142606832, Screen count: 1
Detected configuration: Linux / Mono
Initializing threaded X: success.
Creating default GraphicsMode (24, 16, 0, 0, 0, 2, False).
Creating X11GLNative window.
    Display: 142625560, Screen 0, Root window: 423
    Registering atoms.
    Bits per pixel: 24
    Depth: 16
    Display: 142606832, Screen: 0, RootWindow: 423
    Getting FB config.
    Bits per pixel: 24
    Depth: 16
    Falling back to glXChooseVisual.
    Opening render window... Initalizing X11 input driver.
        First keycode: 8, last 255
        6 keysyms per keycode.
    X11GLNative window created successfully (id: 73400322).
GameWindow 73400322 changing WindowState from Normal to Fullscreen.
Making WindowBorder resizable.
Creating GraphicsContext.
    GraphicsMode: Index: 39, Color: 24 (8880), Depth: 24, Stencil: 0, Samples: 0, Accum: 64 (16161616), Buffers: 2, Stereo: False
    IWindowInfo: X11.WindowInfo: Display 142625560, Screen 0, Handle 73400322, Parent: (null)
    GraphicsContextFlags: Default
    Requested version: 1.0
    Creating X11GLContext context: direct, not shared... 
    Creating temporary context to load GLX extensions.
    Loading extensions for OpenTK.Platform.X11.Glx... 2 extensions loaded in 2.308 ms.
    Using legacy context creation... Context created (id: 143888872).
Making context 143888872 current on thread 1 (Display: 142625560, Screen: 0, Window: 73400322)... done!
Loading extensions for OpenTK.Platform.X11.Glx... 2 extensions loaded in 0.0332 ms.
Context supports vsync: True.
Loading extensions for OpenTK.Graphics.OpenGL.GL... 1900 extensions loaded in 173.8574 ms.
linux:create new window
Creating X11GLNative window.
    Display: 147493376, Screen 0, Root window: 423
    Registering atoms.
    Opening render window... Initalizing X11 input driver.
        First keycode: 8, last 255
        6 keysyms per keycode.
    X11GLNative window created successfully (id: 75497474).
linux:create gfx context
Creating GraphicsContext.
    GraphicsMode: Index: 39, Color: 24 (8880), Depth: 24, Stencil: 0, Samples: 0, Accum: 64 (16161616), Buffers: 2, Stereo: False
    IWindowInfo: X11.WindowInfo: Display 147493376, Screen 0, Handle 75497474, Parent: (null)
    GraphicsContextFlags: Default
    Requested version: 1.0
    Creating X11GLContext context: direct, shared with (143888872)... 
    Creating temporary context to load GLX extensions.
    Loading extensions for OpenTK.Platform.X11.Glx... 2 extensions loaded in 0.0467 ms.
    Using legacy context creation... Context created (id: 147715688).
linux:set gfx context
Making context 147715688 current on thread 2 (Display: 147493376, Screen: 0, Window: 75497474)... done!

I can reproduce this issue using the new "multithreading" example, investigating.

the Fiddler's picture

#2

Posted Monday, 9 November, 2009 - 19:09 by the Fiddler
Status:confirmed» in progress (review)

Should be fixed in rev. 2487, can you please test?

The issue was that there were Xlib calls that were not protected with XLockDisplay/XUnlockDisplay, which presumably caused corruption in the X command stream when using multiple threads.

There's an open question whether GLX calls should be protected like this (right now they aren't ). I haven't been able to find any clear documentation on this issue.

the Fiddler's picture

#3

Posted Monday, 9 November, 2009 - 19:09 by the Fiddler
Version:0.9.9-3» 0.9.x-dev
ebeckers's picture

#4

Posted Monday, 9 November, 2009 - 21:45 by ebeckers

Tested it, but i see nothing different.
Main window still runs in windowed mode and window border is visible:

I found a workaround by calling:

WindowBorder=WindowBorder.Hidden;

WindowState=WindowState.Fullscreen;

ProcessEvents();

just before the GameWindow.Run() call

the Fiddler's picture

#5

Posted Monday, 9 November, 2009 - 21:52 by the Fiddler

Can you please test the "Multithreading" sample in Examples.exe -> OpenTK? Select any window and press spacebar - does it become fullscreen?

If it does become fullscreen, can you please post a short test case that reproduces the issue for you?

the Fiddler's picture

#6

Posted Monday, 16 November, 2009 - 15:16 by the Fiddler
Status:in progress (review)» fixed

I am marking this as fixed (works on my test systems). If this is still an issue in 1.0 beta-2, please reopen the bug.

the Fiddler's picture

#7

Posted Tuesday, 17 November, 2009 - 10:40 by the Fiddler
Version:0.9.x-dev» 1.0-beta-2
Status:fixed» closed

Closing issues fixed in 1.0 beta-2.