Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 03-21-08, 08:14 PM   #1
bootstrap
Registered User
 
Join Date: Dec 2007
Posts: 16
Default help: problems with resize of GLX windows

I just ported my 3D engine from OpenGL on Windows to OpenGL on Linux. But now that I have the core running, I have a couple problems I do not understand. Here is one of them.

When I grab the boundary of the graphics window with the mouse and resize it to a larger size, the area inside the window that is cleared (each frame) does not change size from the original size. The newly exposed area inside the expanded frame is transparent (the desktop is visible). Presumably this means XWindows is (appropriately) not clearing the window, but the OpenGL glClear() continues to clear only the original window dimensions - not the resized/expanded dimensions.

The objects in the window do get larger as the window is resized larger (and printf() statements in the code confirm the viewport and projection matrices are being recomputed and installed correctly (by glViewport() and glLoadMatrixd() calls) every time XWindows sees the window size change). When I resize the window smaller again, some of the window along the top is not drawn - as if the viewport is offset downward (but not rightward).

I do not understand in any significant way what the distinction between the XWindow and GLXWindow are. When my code creates a window, it first calls XCreateWindow() to create an XWindow, then calls glXCreateWindow() to create (and associate) a corresponding GLXWindow. That's what the GLX sample code that I found seems to want. Not sure whether perhaps the XWindow is being resized but not the GLXWindow - but I do not see any GLX resize functions. Furthermore, when I try to resize the GLXWindow with xlib functions, my applications blows up (and XWindows prints a nasty error message). So that doesn't seem to be how this should be handled.

Any ideas?

video card = nvidia 8600GT + 512MB. The nvidia drivers are up to date.
bootstrap is offline   Reply With Quote
Old 03-23-08, 10:30 AM   #2
bootstrap
Registered User
 
Join Date: Dec 2007
Posts: 16
Default Re: help: problems with resize of GLX windows

BTW, I had the same problem with the GLX 1.2 functions (no glXCreateWindow() and several alternate functions). After having so much trouble finding the cause of this problem, I switched over to the newer GLX 1.3 functions - just in case it might fix this.

I finally did solve this problem - after an awful lot of time and effort. To my surprise, the bug is in XWindows, not my code. I definitely did not expect that.

I encountered the problem (by coincidence - or pure bad luck) because I was capturing the width and height of the resized window in the XWindows ResizeRequest event. I found the mere fact of *selecting* to receive this event (when calling the XCreateWindow() function) causes this problem. No kidding! No need to process the event.

In the end, I moved my code that captures the resized width and height of the window into the ConfigureNotify event. Even when my code ignores the ResizeRequest event or simply returns from function --- the problem persists! However, simply clear the bit that selects this event [in the "event_mask" in the XSetWindowAttributes structure argument to XCreateWindow()] and --- poof --- problem gone. Yikes!

Consider this a bug report to whoever cares for X.
bootstrap is offline   Reply With Quote
Old 03-23-08, 02:10 PM   #3
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: help: problems with resize of GLX windows

How are you selecting for these events? If you're using ResizeRedirectMask, then your app is volunteering to be a window manager, essentially, and the X server won't actually resize the window until your app sends a resize request.
AaronP is offline   Reply With Quote
Old 03-23-08, 06:24 PM   #4
bootstrap
Registered User
 
Join Date: Dec 2007
Posts: 16
Default Re: help: problems with resize of GLX windows

Yes, I selected for the ResizeRequest event via the ResizeRedirectMaskBit. However, the only thing I wanted to do (and the only thing I did) was to capture the window width and height values from the event. I stored these values in a structure in my application which is checked whenever glViewport() might need to be called (if the window was resized).

True, I did find another event that gives me the information I need. But still, it seemed quite amazing that XWindows totally malfunctions simply because an application selects to receive a certain event. That is extremely non-intuitive. Off hand, I do not recall any other event on any other similar event/message queue system that dramatically changes behavior just because the application chose to receive information (the event/message).

BTW, I did try to resize the window in the ResizeRequest event at one point, but the call to XMoveResize() it bombed my application. I even tried resizing the XWindow and GLXWindow to see if that made a difference. Perhaps I accidentally passed a bad argument or something, but obviously I didn't think so.

I do not understand what "offering to be a window manager" means. It seems perfectly reasonable that some applications would want to accept this event, then decide (based upon circumstances, conditions, status of the application) whether to resize the window or not --- and whether to position and/or resize to a slightly different size than requested. Though this kind of decision making is more common in window managers than normal applications, I can easily see why an application might want to handle this situation - without taking of *everything* window managers normally do. That seems especially true because it is unusual to want to make one window behave differently than all others in every/most/many respects. Plus why would a programmer want to re-implement an entire window manager just because he needs to do something different with resize?

I think I more-or-less understand the logic of this event now, and believe I understand the problem. Originally I just chose to get my width and height values in this event simply because the event name "sounded right" (as in "resize"). Are there any other events that radically change the behavior of X just because an application asks to receive them? This bug took me a long time to find, because it is not at all intuitive ***before the fact*** to expect the mere fact of selecting an event to totally change the behavior of the window system. True, after the fact it is understandable, but "there must be a better way" that is not so "tricky". However, it is likely decades too late to change the way X behaves.
bootstrap is offline   Reply With Quote
Old 03-24-08, 12:44 AM   #5
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: help: problems with resize of GLX windows

The "Redirect" event masks indicate to the server that you want to redirect processing of those events to your application instead of having them handled automatically in the server. The corresponding "Request" events indicate that the application wants to do something, but that the action hasn't actually happened yet. I agree that it's counterintuitive, but that's just the way that X11 works.

I would suggest reading the Xlib Programming Manual by Adrian Nye. You can get excerpts from it at Google Books.
AaronP is offline   Reply With Quote
Old 03-24-08, 03:33 PM   #6
bootstrap
Registered User
 
Join Date: Dec 2007
Posts: 16
Default Re: help: problems with resize of GLX windows

Okay, I'll check for any event with the "Redirect" term in it. Unfortunately, I left my X books behind when I moved to Maui years ago. I resist buying a new copy because the book appears to be many years if not decades out of date.

Also, I am very much a reality/experimental sort of person in every respect. It is totally natural, habituated, second-nature for me to observe "what things are" and "how things work" rather than read a theoretical discussion (then pretend I actually know something).

So, in this case (per my usual practice), I selected to receive every event. And in my event loop I captured the relevant/significant data from the event structure and printed it out with printf(). To *watch* how something behaves is how I learn - whenever I can.

I guess the only [false/pseudo] comfort I can take away from this experience is this: My habituated modus-operandi gives me a much better practical grasp of things, and *almost* always saves (not costs) me mucho time, effort, trouble, frustration - and bugs.

But I will add this experience to my list of [~two] counterexamples - this and that nasty encounter with the rattlesnake.

Just kidding about the rattlesnake, though. :-)

To everyone who happens to find this message due to a web search for terms bug, resize, ResizeRequest, ResizeRequestMask, XCreateWindow, XSetWindowAttributes, event_mask, xlib, XWindows, glClear, glViewport --- beware (do not select) the ResizeRequest event! Unless you research carefully and thoroughly the consequences of doing so. Start by reading this thread from the beginning. Thanks for your tips Aaron.
bootstrap is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why Windows 8 could be the next Vista News Archived News Items 0 06-15-12 10:30 AM
Like XP or Vista: how will businesses treat Windows 8? News Archived News Items 0 06-06-12 09:10 AM
NVIDIA Brings 18 Years of Experience to Windows 8 News Archived News Items 0 06-03-12 06:20 AM
Sync it up: Hands on with the preview of Windows 8's cloud sync service News Archived News Items 0 06-02-12 08:30 PM
Glx mrbig1344 NVIDIA Linux 7 09-30-02 06:45 AM

All times are GMT -5. The time now is 07:23 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.