Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
Cheers, Marcin.
Am Sonntag, 7. Mai 2006 13:47 schrieb Marcin Kardas:
Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
Are you the same person as gamemaker@tlen.pl?
Well, basically check out http://wiki.winehq.com/SummerOfCode, it contains some information you need. Basically you're a bit late, applications should be in by tomorrow.
AFAIR this problem was discussed here, and windowed opengl might be a case for soc. It also affects Direct3D8 and Direct3D9 apps, and will affect Direct3D <=7 and DirectDraw apps with my ddraw rewrite.
On Sun, May 07, 2006 at 01:47:54PM +0200, Marcin Kardas wrote:
Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
One of the hard things about the glScissor approach is coping with clipping other child windows. Have you thought about how to do this yet?
Huw.
2006/5/8, Huw Davies h.davies1@physics.ox.ac.uk:
On Sun, May 07, 2006 at 01:47:54PM +0200, Marcin Kardas wrote:
Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
One of the hard things about the glScissor approach is coping with clipping other child windows. Have you thought about how to do this yet?
Huw.
Huw Davies huw@codeweavers.com
I've writen (very) simple test program for Linux, you can download it from: http://www.gamemaker.host.sk/soc/gltest.c
This program, like Wine, is using only one X window, and other GL scenes are emulated. I can to this same for Wine, and it will be first real improvement, because many GL scenes now will be working parallel and will be drawed in good place (not like now, when everything is drawed in lower-left corner). The second and the last improvment and the hardest one, is to 'synchronieze' GLXContext with X Window Context. Maybe I will have to draw Wine subwindows by OpenGL in this same GLXContext (I'm not sure if it is acceptable), or just draw GL on this same Pixmap.
* On Mon, 8 May 2006, Marcin Kardas wrote:
I've writen (very) simple test program for Linux, you can download it from: http://www.gamemaker.host.sk/soc/gltest.c
This program, like Wine, is using only one X window, and other GL scenes are emulated.
Oh, if I run wine make process in parallel, then this app acts so slow and lags my box (mouse): load average: 2.44, 1.77, 1.76
If I suspend parallel compilation, X starts using 75% of CPU while gltest only about 15%. No window overlapped one of gltest during test, AFAIK.
FWIW, I run Celeron 850 + GeForce2 MX. (with NVIDIA native drivers v8178)
2006/5/7, Marcin Kardas marcin.kardas@gmail.com:
Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
Cheers, Marcin.
On http://wiki.winehq.org/OpenGL there is written, that someone has tried to fix this bug like this - map Windows' window with X window one to one (it was my first idea). But there is also written, that
" having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications)".
Does anybody know what type of problem it was - may be unfortunately programmer make another bug in code while solving this one??
If AJ removed it, it wouldnt have been just a simple bug that caused problems, it would have had to be something either about the way Windows' windows work vx X11's windows, or maybe the way it was implemented as a whole was just wrong and so therefore it caused some problems. If it was the latter though, I would think that AJ would have just written the same 1:1 mapping with his own code from scratch, so it is probably just that the 2 windows were too incompatible to properly (without problems) do 1:1.
On 5/10/06, Marcin Kardas marcin.kardas@gmail.com wrote:
2006/5/7, Marcin Kardas marcin.kardas@gmail.com:
Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it?
Cheers, Marcin.
On http://wiki.winehq.org/OpenGL there is written, that someone has tried to fix this bug like this - map Windows' window with X window one to one (it was my first idea). But there is also written, that
" having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications)".
Does anybody know what type of problem it was - may be unfortunately programmer make another bug in code while solving this one??
"Marcin Kardas" marcin.kardas@gmail.com writes:
On http://wiki.winehq.org/OpenGL there is written, that someone has tried to fix this bug like this - map Windows' window with X window one to one (it was my first idea). But there is also written, that
" having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications)".
Does anybody know what type of problem it was - may be unfortunately programmer make another bug in code while solving this one??
It's not just a simple bug, it's fundamental incompatibilities between Win32 and X11 windows WRT clipping and repainting, not to mention inter-process issues. We really don't want to go back to having an X window for every Win32 window.
On Thu, 11 May 2006 11:48:31 +0200, Alexandre Julliard wrote:
It's not just a simple bug, it's fundamental incompatibilities between Win32 and X11 windows WRT clipping and repainting, not to mention inter-process issues. We really don't want to go back to having an X window for every Win32 window.
Incidentally, when are we going to get toggle_managed(HWND wnd) ? This was supposed to be one of the big wins of the WM rewrite; we still have apps like Steam that are sooooooo close to working perfectly, if only we can nail app windows being created override-redirect :)
thanks -mike
On Thursday 11 May 2006 11:48, Alexandre Julliard wrote:
"Marcin Kardas" marcin.kardas@gmail.com writes:
On http://wiki.winehq.org/OpenGL there is written, that someone has tried to fix this bug like this - map Windows' window with X window one to one (it was my first idea). But there is also written, that
" having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications)".
Does anybody know what type of problem it was - may be unfortunately programmer make another bug in code while solving this one??
It's not just a simple bug, it's fundamental incompatibilities between Win32 and X11 windows WRT clipping and repainting, not to mention inter-process issues. We really don't want to go back to having an X window for every Win32 window.
Well, can be possible to have a particular case for opengl/ddraw/d3d applications (ie. GLX needed applications) ? As for GLX code is a lot better to have separate X windows (as GLX context is per windows).
I was thinking first to force creation on an GLXWindow when first enabling openGL, to solve most of the problems of wglShareLists.
Anyway, this don't solve all cases of 2398 bug (only multi windows bugs) remains intra windows gl contexts
Regards, Raphael
gltest once again - see attachment. This time you can move windows with mouse (but don't go out of main window or resize main window).
On Monday 15 May 2006 12:33, Marcin Kardas wrote:
gltest once again - see attachment. This time you can move windows with mouse (but don't go out of main window or resize main window).
Funny demo :)
Regards, Raphael