Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...
On Mon, Jan 31, 2005 at 10:34:07AM -0600, Alexandre Julliard wrote:
Log message: Only create an X window for top-level windows, not for child windows. Get rid of the X client window too, it's no longer needed.
Cool. Does this mean that the window management rewrite is done? -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Cool. Does this mean that the window management rewrite is done?
The bulk of the architectural work is done, yes. There are still many loose ends to tie up, and some missing performance improvements. Plus of course fixing all the regressions that this change will cause, notably with OpenGL... -- Alexandre Julliard julliard(a)winehq.org
On Mon, Jan 31, 2005 at 08:26:24PM +0100, Alexandre Julliard wrote:
The bulk of the architectural work is done, yes.
This is a big day then -- pretty cool stuff.
There are still many loose ends to tie up, and some missing performance improvements. Plus of course fixing all the regressions that this change will cause, notably with OpenGL...
If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :)) -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :))
It's a bit hard to build a complete list, I mostly make it up as I go... The main optimisation I know about is the repainting on window moves that needs to copy the bits instead of invalidating the whole window. The loose ends are mostly related to dll separation, the exported functions in user32.spec can give you a rough idea of what remains to be done. For OpenGL what we need is to implement proper clipping when drawing to a child window. There are also a number of window management hacks in the Crossover tree that need to be cleaned up and brought over. -- Alexandre Julliard julliard(a)winehq.org
On Mon, Jan 31, 2005 at 09:11:30PM +0100, Alexandre Julliard wrote:
The main optimisation I know about is the repainting on window moves that needs to copy the bits instead of invalidating the whole window.
Well, I guess that's worth doing, it would save quite a few artifacts.
The loose ends are mostly related to dll separation, the exported functions in user32.spec can give you a rough idea of what remains
True, but those are really part of the dll separation task, it's not quite fair to lump them into this one :)
For OpenGL what we need is to implement proper clipping when drawing to a child window. There are also a number of window management hacks in the Crossover tree that need to be cleaned up and brought over.
Speaking of bugs, the old bug #1091: http://bugs.winehq.org/show_bug.cgi?id=1091 Is still not fixed. I've attached a screenshot of what happens if you move a window that's on top of a listbox that scrolls in the background. To me it looks there is a race of sorts, and the scrolling happens but somehow the invalidated region is not expanded correctly. -- Dimi.
If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :))
Basically, the problem with OpenGL is that there is no way (that I know of) in OpenGL to do non-simple clipping (what I mean by 'non-simple' is non-rectangular). Ie if a (non top-level) OpenGL window is obscured by another (non top-level) window, there is no way (that is not a hack) to prevent GL to draw over the obscured window. The best way to fix this would be to have the X server export via a GLX extension its hardware clip-list implementation (which is something that I need to discuss with the FreeDesktop guys as this would be something that could help all the 3D X servers implementations which people are working on as, basically, it's exactly the same issue). The other way is to do indirect rendering for GL contexts not associated to top-level windows: basically, draw in a Pixmap (or a PBuffer) and then use the plain Wine 'DIB' code to blit this back-buffer to the screen (doing then the clipping). This should work easily at the price of some performance (especially on cards / drivers who do not support accelerated off-screen rendering). The additionnal advantage of the latter solution is to solve also the 'multiple windows / different GL attributes' problem. Lionel PS: I think we may have the same issue if we want (one day) to re-introduce Xv acceleration for video playback. -- Lionel Ulmer - http://www.bbrox.org/
participants (3)
-
Alexandre Julliard -
Dimitrie O. Paun -
Lionel Ulmer