Re: Internal-wm/rootless observations
Alexander Gottwald wrote: Maybe the odd window width is the problem. Thinking about it revealed that each pixmap line _must_ start at a boundary. assuming 8bit mode and a window with width 1 at (0, 0) pixmap starts at 0x100 screen base is at 0x100 (no problem) moving the pixmap by 4 pixel down screen base is 0xfc now moving 1 pixel up screen base is still 0xfc We have no way to distinguish where to start. fbCopyNtoN just adds the stride size to the base and lands somewhere in the wild. But each line must begin at a 32 bit boundary and distinct lines must have distinct offsets. ensuring the pixmap width (in bytes) is always a multiple of 4. Every line starts at a 32bit boundary. bye ago NP: In Strict Confidence - Sleepless -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Internal-wm/rootless observations
After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. I can reproduce the problem when I change 16bit mode. Usually I use 32bit mode, so I couldn't. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with Could you give me diff? I want to try that. I think we have no reason to use winshadgdi.c in mwextwm mode and some code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? Thanks in advance. -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Kensuke Matsuzaki wrote: Could you give me diff? I want to try that. Actually not. Most changes where done in gdb with set var ;) let's do it from memory: in winMWExtWMStartDrawing: hdcNew = CreateCompatibleDC (pRLWinPriv-hdcScreen); /* Describe shadow bitmap to be created */ pRLWinPriv-pbmihShadow-biWidth = pRLWinPriv-pFrame-width;//pRLWinPriv-dwWidth; pRLWinPriv-pbmihShadow-biHeight = -pRLWinPriv-pFrame-height;//pRLWinPriv-dwHeight; + pRLWinPriv-pbmihShadow-biBitCount = 32; /* Create a DI shadow bitmap with a bit pointer */ in winAdjust - /* Query GDI for current display depth */ - dwBPP = GetDeviceCaps (hdc, BITSPIXEL); + /* Set the colordepth to 32 to please rootless code */ + dwBPP = 32; /* GDI cannot change the screen depth */ This is in no way safe and should be wrapped with a check for -internalwm but safe for testing I think we have no reason to use winshadgdi.c in mwextwm mode and some code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? I don't think so. We have way too much code anyway i think. 5 different engines, to code for handling windowed, pseudorootless and rootless code. If we find a safe way to blit from 32bit planes to 16bit planes then this will be quite useful in shadow GDI mode too. Sebastian Haby told me the 8bit pseudocolor patch he made has similar code (blitting from a 8bit plane to 32/24/16 bit). I'll have to check the mail archives at home for this code bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Internal-wm/rootless observations
I have been away on a long Thanksgiving vacation so I've been slow to respond. In any case, the 16 bpp modes are problematic but I believe we solved issues with them in the rootless code awhile back. The fundamental problem is that fb assumes screens are always 32-bit aligned. Thus you if a window's pixmap is not 32-bit aligned, fb assumes it can still access the word before the start of a drawable's data. In rootless mode, where windows are located higgledy-piggledy in memory, this is not true. Rootless solves (or attempts to solve) this problem with the SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that the unaligned window's pixmap is moved backwards in memory to align it and then a positive offset it given to fb to indicate where the window resides in the pixmap. If there is an edge case where rootless does not work in 16-bits it would be good to track down. This mode is sometimes used on Mac OS X. Hopefully that is helpful. I've got a review today but I can look at this in more detail tomorrow. --Torrey At 4:45 PM +0100 11/30/04, Alexander Gottwald wrote: Hi all, After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with CreateCompatibleBitmap() bitmap-width = width bitmap-height = height bitmap-bpp = dbBPP CreateDIBSection() BitBlt(windowdc, ..., shadowdc, ...) was not working properly. Is CreateCompatibleBitmap reusing the DC from the screen? How can I create a 32bit bitmap if the desktop is running in 16bit? Anyway. Setting the bitmap depth to 32bit fixed the crashes I had the last weeks with rootless but garbled the output. So the goal is to have everything inside the server running at 32bit and let GDI do the colorspace translation from 32 to 16 or 24 bit. @zakki: I've found this in the code if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); winMWExtWMMoveResizeXWindow (pWin, shouldn't that be if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); else winMWExtWMMoveResizeXWindow (pWin, bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Torrey Lyons wrote: I have been away on a long Thanksgiving vacation so I've been slow to respond. No problem. I'm hunting this for some weeks already In any case, the 16 bpp modes are problematic but I believe we solved issues with them in the rootless code awhile back. The fundamental problem is that fb assumes screens are always 32-bit aligned. Thus you if a window's pixmap is not 32-bit aligned, fb assumes it can still access the word before the start of a drawable's data. In rootless mode, where windows are located higgledy-piggledy in memory, this is not true. Rootless solves (or attempts to solve) this problem with the SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that the unaligned window's pixmap is moved backwards in memory to align it and then a positive offset it given to fb to indicate where the window resides in the pixmap. If there is an edge case where rootless does not work in 16-bits it would be good to track down. This mode is sometimes used on Mac OS X. Maybe the odd window width is the problem. Testcase: xterm width 501 pixel http://www-user.tu-chemnitz.de/~goal/Xming/internalwm.png setting the with to 502 pixel in the debugger solved the distorted drawing. assuming the base was 0x2b0. After the window was translated by (0,5) the pixmap base was moved by 5 * 1002 bytes. In the fb drawing functions the offset was never correct to 0x2b0. It was still below that value and the access an access violation. I had problems with fbCopyNtoN and fbBlt. SetPixmapBaseToScreen does: ptr = 0x2b0 - 5 * 1002 = 0x2afec6e This is unaligned - fixing this ptr = 0x2afec6e - 2 = 0x2afec6c fbCopyNtoN does dst + (pbox-y1 + dstYoff) * dstStride so this is 0x2afec6c + (0 + 5) * 1002 = 0x2ae - unaligned and _off pixmap_ bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Internal-wm/rootless observations
Hi all, After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with CreateCompatibleBitmap() bitmap-width = width bitmap-height = height bitmap-bpp = dbBPP CreateDIBSection() BitBlt(windowdc, ..., shadowdc, ...) was not working properly. Is CreateCompatibleBitmap reusing the DC from the screen? How can I create a 32bit bitmap if the desktop is running in 16bit? Anyway. Setting the bitmap depth to 32bit fixed the crashes I had the last weeks with rootless but garbled the output. So the goal is to have everything inside the server running at 32bit and let GDI do the colorspace translation from 32 to 16 or 24 bit. @zakki: I've found this in the code if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); winMWExtWMMoveResizeXWindow (pWin, shouldn't that be if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); else winMWExtWMMoveResizeXWindow (pWin, bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Internal-wm/rootless observations
Hey Alex! If you want to allocate a 32bpp DIB section even though the desktop is 16bpp take a look at the winshadgdi.c:winAllocateFBShadowGDI() i sent you that fixes 8bpp pseudocolor while running the desktop in 16/32bpp. Cheers, Sebastian Haby
