Home » Extra libraries, Code snippets, applications etc. » U++ users applications in progress and useful code snippets, including reference examples! » An OpenGL ctrl for Linux / X11
An OpenGL ctrl for Linux / X11 [message #3578] |
Fri, 02 June 2006 18:40  |
 |
cyrion
Messages: 15 Registered: May 2006 Location: Grenoble, France
|
Promising Member |
|
|
Hi,
I have just finished (the first version of) an opengl ctrl for X11.
It works well but I had to make modifications to U++ core, and I would like to know if there is a best way to proceed.
The modifications I have made are:
1/ in CtrlCore.h, class Ctrl :
* I put the static ArrayMap<> Xwindow() in protected section.
I had to do so because the Create() method does not allow to use another X visual than the top window one. So I had to put my new X (sub)window "by hand" into the static ArrayMap of windows.
* I added a 'bool UseGLXVisual' (in protected section), defaulting to false except in my new Ctrl.
2/ in X11Wnd.h
* in Ctrl::DoPaint(), I 'return' without creating a GC if UseGLXVisual is true (just before XCreateGC).
I had to do so to prevent the Ctrl::Draw() method to be called with a GC context that is not compatible with my X window.
Finally, all seems to work fine : resizing, moving, hide/show, multiple gl ctrls, etc...
I hope that the source code will be more comprehensible than my english.
Btw, _many_many_ thanks for this wonderful library !
Damien
(Linux 2.6, debian, Xorg, U++ 605)
|
|
|
|
|
|
Re: An OpenGL ctrl for Linux / X11 [message #3608 is a reply to message #3607] |
Tue, 06 June 2006 17:59   |
 |
mirek
Messages: 14255 Registered: November 2005
|
Ultimate Member |
|
|
cyrion wrote on Tue, 06 June 2006 10:02 | Hi,
I am aware of the GL Ctrl working on Windows, that's exactly why I made the posix version 
What I wanted to know was if there was a best way to proceed, i.e. while avoiding modifying the core of Upp.
If all seems ok, I could make it portable with a couple of #ifdef in the Upp GLCtr, and if you are interested, you could use it for the next release.
This would be my first contribution to Upp !
|
Perfect!
That would be an important milestone, as by that act, we would finally reach Linux/Win32 parity (because other things like printing and clipboard are being resolved now as well).
BTW, IMO "UseGLXVisual" could be replaces by existing "BackPaint(EXCLUDEPAINT)".
Mirek
|
|
|
Re: An OpenGL ctrl for Linux / X11 [message #3609 is a reply to message #3608] |
Tue, 06 June 2006 19:48   |
 |
cyrion
Messages: 15 Registered: May 2006 Location: Grenoble, France
|
Promising Member |
|
|
luzr wrote on Tue, 06 June 2006 17:59 |
BTW, IMO "UseGLXVisual" could be replaces by existing "BackPaint(EXCLUDEPAINT)".
|
I have just tested BackPaint() but it doesn't work because DoPaint() is still called with a bad X visual
I get things like that :
X Error: BadDrawable (invalid Pixmap or Window parameter), request: X_CreateGC, resource id: 136899272 = 828EAC8
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_FreeGC, resource id: 48234558 = 2E0003E
IMHO, instead of using a variable like my dirty UseGLXVisual it would probably be best to take into account the fact that some controls can require special visuals that does not require a Draw object to be created. But I don't know how ! (a kind of BackPaint(3DPAINT) ?)
In the end, I think that Ctrl::Paint() should still be called, but with a 'null/disabled' Draw object in parameter...
|
|
|
Re: An OpenGL ctrl for Linux / X11 [message #3611 is a reply to message #3609] |
Tue, 06 June 2006 22:46   |
 |
mirek
Messages: 14255 Registered: November 2005
|
Ultimate Member |
|
|
cyrion wrote on Tue, 06 June 2006 13:48 |
luzr wrote on Tue, 06 June 2006 17:59 |
BTW, IMO "UseGLXVisual" could be replaces by existing "BackPaint(EXCLUDEPAINT)".
|
I have just tested BackPaint() but it doesn't work because DoPaint() is still called with a bad X visual
I get things like that :
X Error: BadDrawable (invalid Pixmap or Window parameter), request: X_CreateGC, resource id: 136899272 = 828EAC8
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_SetClipRectangles, resource id: 48234558 = 2E0003E
X Error: BadGC (invalid GC parameter), request: X_FreeGC, resource id: 48234558 = 2E0003E
IMHO, instead of using a variable like my dirty UseGLXVisual it would probably be best to take into account the fact that some controls can require special visuals that does not require a Draw object to be created. But I don't know how ! (a kind of BackPaint(3DPAINT) ?)
In the end, I think that Ctrl::Paint() should still be called, but with a 'null/disabled' Draw object in parameter...
|
Well, I have not studied your version in detail and in fact, I never really understood concept of X11 visuals, however...
Normal U++ widgets do not have corresponding objects (handles) in neither X11 or Win32 - U++ normally uses just top-level windows. That in turn means that there is only single Draw for each top-level Ctrl.
That of course is sometimes trouble - e.g. for OpenGL which requires separate GUI object. In order to solve that, there is special DHCtrl class, so far implemented in Win32 only, which has corresponing object (HWND) in Win32 and handles WM_PAINT completely separately. BackPaint(EXCLUDEPAINT) just clips the content of DHCtrl out of normal painting procedure (which is always called for entire top-level Ctrl). I believe that Linux should, if possible, follow the path. GLCtrl is derived from DHCtrl.
Mirek
|
|
|
Re: An OpenGL ctrl for Linux / X11 [message #3622 is a reply to message #3578] |
Thu, 08 June 2006 07:00   |
 |
cyrion
Messages: 15 Registered: May 2006 Location: Grenoble, France
|
Promising Member |
|
|
Hi,
I checked on windows to see how it works. I'm not sure, but I think that BackPaint(EXCLUDEPAINT) does the job for Windows, but not exactly in the same manner for Linux because the GC is always created.
While using BackPaint(EXCLUDEPAINT), my problem disappear only if I don't call the inherited EventProc() of Ctrl in my OpenGLCtrl::EventProc, but in this case Frames are never painted !
I run out of ideas.
In addition, a desirable feature would be that Ctrl objects (at least GL ctrls) receive a 'POSITION' event. Currently I have to watch for a modification of the widget position each time Paint is called, which slows down rendering.
BTW, the windows version of the gl ctrl does not handle displacements of the ctrl. For instance, try to use win.Add( gl.BottomPos( 0, 120).RightPos( 0, 120 ));
In the attached file I put a small app using the new version of the Ctrl. It now handles multiples GL widgets on the same app automatically.
Damien.
|
|
|
|
Re: An OpenGL ctrl for Linux / X11 [message #3633 is a reply to message #3632] |
Fri, 09 June 2006 18:01   |
 |
cyrion
Messages: 15 Registered: May 2006 Location: Grenoble, France
|
Promising Member |
|
|
Mirek, thanks for your quick answers and your patience.
After many hours checking U++ source code as well as my source code, I think there are some bugs into the core:
pb#1: my widget never receive LAYOUTPOS when the position change. However LAYOUTPOS is received when it is resized.
pb#2: when I put my gl ctrl into a TabCtrl, itself contained into another TabCtrl, my function RectInTopWindow
Rect OpenGLCtrl::RectInTopWindow() const
{
return GetScreenView() - GetTopCtrl()->GetScreenRect().TopLeft();
}
does not return a good value. I suspect that GetTopCtrl() does not return the good top ctrl.
pb#3: My new x subwindow with a special visual generates X errors when Paint() is called, except if I use my IsGLXVisual variable to prevent DoPaint to create a graphics context.
If I use BackPaint(EXCLUDEPAINT), I can get rid of X errors if I don't call the inherited Ctrl::EventProc(w, event), void OpenGLCtrl::EventProc(XWindow& w, XEvent *event)
{
// Flush 'Expose' events
while( XCheckWindowEvent( Xdisplay, SubWindow, ExposureMask, event )) {};
if( IsMapped )
OpenGLPaint();
Ctrl::EventProc(w, event );
} but in this case the frames surrounding my Ctrl (like InsetFrame for instance) are not displayed anymore.
pb#4: When the app window is resized, my ctrl receive a lot of SHOW events, that make my X subwindow swapping to hide/show state. This slows down the resizing process in this case (that is, a X sub window, not a standard ctrl).
If you have time for that, please look at my source code. It would be a great help for me to find if I made a mistake or don't understand something. At this point, I have no more ideas to make my GL Ctrl working without modifying the U++ core.
Sincerely,
Damien.
[Updated on: Fri, 09 June 2006 18:01] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 25 21:23:51 CEST 2025
Total time taken to generate the page: 0.01344 seconds
|