Re: Icons [in Server Test 87]
Howdy Lev and Colin... -- Original Message - Subject: Re: Icons [in Server Test 87] I thought we were OK at 32bpp (1280x1024) until I looked again! Device dependence maybe, I'm got an old ATI Rage Pro card (don't ask why?). It's the black and white icon's images that's are going wrong not the masks. The black (0) is rendered transparent. --- Lev's got an ATI too, so that seems to be the common thread. Luckily my laptop has a Rage Mobility so I might be able to reproduce this and see what's shaking with it. My Rage Pro is sitting in a box somewhere, ATI had the worst driver support I've ever seen back in the W95 days. Also, the mask, not the bitmap that's not working. The mask is what gives you black, the icon gives you the white: the way Windoze does an icon is first take MASK BACKGROUND (giving black or the background) and then takes the (MASKBACK) | ICON (giving white/color or the masked off black or the unmasked background). I've just started a trace on this one:- On xclock I get 6 calls on winScaleXBitmapToWindows effBPP=32 effXBPP=1 effXDepth=1 effBPP=1 effXBPP=1 effXDepth=1 effBPP=32 effXBPP=1 effXDepth=1 repeat effBPP=32 effXBPP=1 effXDepth=1 effBPP=1 effXBPP=1 effXDepth=1 effBPP=32 effXBPP=1 effXDepth=1 The effBPP=1, effXBPP=1 followed by the effBPP=32, effXBPP=1 are the mask generation stages. I make a mask and then need to set all non-masked areas to 0 (since we'll be doing an OR and we don't want unmasked areas to show at all)... - The 1st and 4th are the image passes. If I nobble these passes (effXBPP=1 and effBPP=32) (leaving the 3rd and 6th mask pass unchanged) and bodge in say 127 to case32 outPtr's (4 times the same to the break) instead of the original 4x0 fall through; I get white and 'grey' (i.e. the outline and hands are no longer transparent!). I'm just a born hacker and can't resist mucking about in someone else's algoryrhymes! Some endian problem perhaps? --- That gray's probably because the mask isn't set to anything, so the OR combines the background and the image giving a kinda funky alpha type blend. There's definitely not an endianness problem, all X86 cards expect bits in the same place, thankfully! What is really funky is you say that xload does this too. Xload doesn't have a mask so I generate a solid black one (meaning you should get a solid white background on which to draw the black bars and graph in the icon)... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Icons [in Server Test 87]
Howdy Colin,
At 01:30 AM 5/31/2003 +0100, you wrote:
I just love ATI, great hardware... pity about the software!
They had and still have the best TV out support. I wish my GF or
Voodoos had 1/2 the configurability.
Here's my 'results' (attached) using Harold's Test87 binary at 32bpp
1280x1024 on my antique ATI Rage Pro!
xload xclock looks dodgy, yes it's all a black and white problem!
Thx, it looks like the mask is not working at all when you have
a 32bpp icon map and a 1bpp icon mask. White's a 255,255,255 tuple
so when you OR it with anything you get 255, so it'll show up white
no matter what...
I just realized my laptop doesn't have cygwin installed, so it may be
a bit before I can do local testing. One thing I'd like you to add
is a check after the ii.mask = CreateBitmap() call, that the returned
value isn't NULL. Also, can you dump the image planes, I'm assuming
that planes==1 everywhere because I never heard of it being otherwise
except in 16-color (4bpp!) mode...
winmultiwindow.c line2198 or so...
/* Create Win32 mask from pixmap shape */
ii.hbmMask = CreateBitmap (iconSize, iconSize, planes, 1, mask);
+ ErrorF(Planes: %d\n, planes);
+ if (iihbmMask==NULL)
+ {
+ LPVOID lpMsgBuf;
+
+/* Display a fancy error message */
+ FormatMessage (FORMAT_MESSAGE_ALLOCATE_BUFFER |
+FORMAT_MESSAGE_FROM_SYSTEM |
+FORMAT_MESSAGE_IGNORE_INSERTS,
+NULL,
+GetLastError (),
+MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+(LPTSTR) lpMsgBuf,
+0, NULL);
+
+ ErrorF (Mask creation failed, error %s\n,
+ (LPSTR)lpMsgBuf);
+ LocalFree (lpMsgBuf);
+ }
All the rest are fantastic!!!
That's REALLY a kicker, the same kind of mask creation is done without
regard to the source image depth!
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Re: Icons [in Server Test 87]
Hi Colin and Lev: Here's a fix for 32bpp icons on ATI machines. It turns out that I was setting an alpha value which is technically not supposed to be set in each 32bpp pixel. 3dfx and nVidia drivers ignore the value, but ATI looks looks at it and says, Whoa, junk this bitmap! Tests on my laptop @32bpp run A-OK whereas the old code had the same problem you're seeing. This is a diff against test87 clean... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com icon_ati.diff.bz2 Description: Binary data
Re: Custom icons + MouseUp fix
Howdy Harold, At 11:45 PM 5/30/2003 -0400, you wrote: Any reason we shouldn't install a message hook when the user presses and holds a mouse button or modifier key? I'm not sure what you mean by this, do a mouse capture? This may change the semantics, because then any drop-target window won't get any mouse messages since only one window is allowed to see the mouse moves/buttons. On a related note, what is up with winmultiwindowwindow.c/winTopLevelWindowProc()/WM[NC]MOUSELEAVE and the SetTimer call? This must have been something that Kensuke did without me looking too closely :) It looks like it is used to move the X cursor out of the screen view when the user moves the mouse out of the X window... but it never calls KillTimer in the processing of WM_TIMER, which is strange. It looks like this could also be used to move the mouse cursor if it shows up over another X window... but that should be handled by the WM_MOUSEMOVE processing for that new window. Do you see any reason we can't get rid of these timers? I would really like to avoid them if possible. I think what he was trying to do was to update the mouse position in the root window when the mouse isn't over any X window, since you only get mousemoves if the mouse is over your window. Removing the timers would kill things like xeyes and the drag-n-drop icon movements in some of the KDE/QT/whatever apps. In multi-window-mode the root window would then only get messages when the mouse was inside the client area of one of the apps... Even if he doesn't KillTimer, since he is reusing the event id it shouldn't cause any kind of leak. And he does kill it on a mousemove on the initiating window. However I think he has a bug here, it seems he will create a timer for each X window, not one for the entire application. You can test this by restarting the server and running xeyes. Move your cursor around on the desktop, outside the window and see how the eyes only update once per second or so. Now, open up 20 x terms and move your mouse through each, just to start their timers. Finally, with those 20 windows up move your mouse outside them on the Windoze desktop and you'll notice the eyes are following in real time, much faster than before. As bugs go it's pretty benign, and would take another global variable to hold the timer ID to fix... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Howdy Harold, let me just say thanks for the efforts you've been giving while trying to herd cats^Wpatches... At ***02:37 AM*** 5/29/2003 -0400, you wrote: 11) Try, in vain, to maintain a uniform coding style and variable/function naming convention. I am mostly winning the curly-brace (curly braces on separate lines please), indenting (emacs ... Please replace local source with source from test release, reapply local patches to test source, and submit new patches as needed. :) I have made lots of style fixes to the source, so you might as well replace all files... otherwise diffs will be useless for me as they were quoting hundreds of lines of source that were logically equivalent but stylistically different. [Anybody about to send me a diff command that ignores whitespace, don't... that isn't what I am looking for.] All the old changes look to work great! I got my Debussy and NCVerilog icons, title bars, etc. without a single change. I am also attaching what I hope is a style-conforming patch for the missed mouseup messages. The problem is that Windows will not give you a WM_[LMR]BUTTON[UP/DOWN] unless the mouse is over a window you own. To get around this I put in a check in the WM_TIMER which is already in there to kludge WM_MOUSEMOVEs when the pointer is not in an X owned window. It's gone through 2 days of me beating on it for real work and it seems OK. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com buttonrelease.diff.bz2 Description: Binary data
RE: Custom icons per window class/name patch
Howdy Colin, At 03:21 PM 5/28/2003 +0100, you wrote: ...It shows the task switcher icons with:- 3) ghostview (!) 3) konqueror (showing transparency fault) 4) xeyes and xclock (ok) Are you sure you have all the patches in? #4 xclock is actually a watch icon, with a black strap at the top and bottom whenever I run under 16 or 32 bit mode #3 gv looks more like ghostview has a 50% grey dither around the icon, no? In that case because of the scaling artifacts from xxx-32 you'll get that kind of effect, especially at 1-bit deep. I'll see if I can find anything since it's common between 32 and 16 bit modes. Icons larger than 16x16 seem to have OK 1-bit masks, it's pretty odd! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Colin et. al, There is a quick, easy fix for the 16x16 bitmask icon problem. At winmultiwindowwindow.c, line 1961 there's an if statement: if (iconPtr-drawable.width 16 || iconPtr-drawable.height 16) iconSize = 32; else iconSize = 16; Replace it completely with just iconSize = 32 and all your problems are solved. There are assumptions that are made in the scaler that aren't valid for sub 32-bit wide icons or masks, and since the scaler can increase as well as decrease the image, it all works just fine. -- Original Message - Subject: RE: Custom icons per window class/name patch From: Colin Harrison [EMAIL PROTECTED] .. I don't get the xclock watch icon on my remote linux boxes either, (RedHat 8.0 and 7.3, KDE) using XFree86-4.2.0-72 and XFree86-4.2.0-8 which are RH's latest released rpms for these disto versions! Cygwin is at 4.2.0-1. Looks like a red herring anyway, I can't fault any 'normal' (as in longstanding) X app icon handling through XWin! Could be, it's not too big of a deal anyway since the masks seem to be OK (OTW you would have a non-white clock face...) -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Custom icons + MouseUp fix
Howdy Colin, glad to hear it's working 100%. The original problem was the endianness of Windoze 1-bit bitmap when using a non-32-bit wide destination. I think the code was writing into the unused portion of the 32-bits and you got garbage in the real mask part. I found some kde apps on a linux box and did some peeking, it seems that not many register a small 16x16 icon, and that konqueror, for example, only gives a 16x16 icon in its _NET_WM_ICON property anyway. Very strange, maybe that _NET_ICON thing isn't commonplace? Things like KPAINT, KCALC, and KILLUSTRATOR (great name, the kill-ustrator) have big icons by default in WM_HINTS. Today I also got to test a fix for the missed ButtonRelease problem (dragging an Xterm scrollbar outside of its window and releasing the button does not tell Xterm it was released, leading to interesting problems). One thing I had to do that I don't like is to use a local copy of what the winmultiwindowwindow.c thinks is the button state. (i.e. LBUTTON=down, MBUTTON=up, RBUTTON=up) It did seem to work the entire day of hard use w/o any problems, but I have the suspicion that it might sometimes get out-of-sync w/the X server and send two ButtonReleases. That'd be better than the present situation but could still cause problems with pasting twice... Is there a simple mi* or dix* call to get this info directly instead of keeping a cached copy? I did a grep but didn't find anything promising. You can't call XQueryPointer() since that's only legal for a client to do. I suppose I could post something to the WM thread but that's a real ugly kludge. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Howdy Harold, At 12:04 AM 5/29/2003 -0400, you wrote: Whatever you do, don't send a patch for the mouse release fix until I can make another test release. I am getting swamped with patches here. Thanks. OK, truce! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Few minor issues
Howdy Biju, Harold: At 12:03 AM 5/29/2003 -0400, you wrote: Biju wrote: I dont know whether others noticed these. 1) After we start XWin.exe the mouse pointer will automatically move to center of screen. This is OK for normal mode, -nodecoration and -fullscreen. But I think its not needed in -multiwindow and -rootless modes. I looked for the code that does this (it is general X code, not Cygwin/XFree86-specific code) the last time that someone brought this up (wasn't it you?). I could not find the code and I won't be looking for it again. Someone else can do the searching of the source code tree under xc/programs/Xserver to try to find it. It is most likely in xc/programs/Xserver/hw/os or xc/programs/Xserver/hw/dix, but I couldn't find it in either of those directories. Well, you could always throw out the 1st cursor positioning call since it is guaranteed to be from the X server itself and not an application. That way you do not have to modify any of the standard X server code, just the xwin/ directory files... ...To hide from taskbar we may be able to use WS_EX_TOOLWINDOW flag for EXSTYLE attribute. I am attaching an example for this. Hiding from the taskbar? It isn't shown on my taskbar. I am using Windows XP... what version are you using? It doesn't show up under W2K either. I also noticed that an already existing exit dialog was not being brought to the foreground when the user performed another action that would display the dialog. The result was that the dialog box seemed to be lost and it seemed that you couldn't exit Cygwin/XFree86. I changed this to call SetForegroundWindow () for the dialog box when it already exists. This brings it to the top in response to such user-generated events. Any ideas on how to get rid of the Maximize button on the dialog? I can do it by removing the WS_SYSMENU style... should we be using WS_SYSMENU or not? Not using WS_SYSMENU cause our icon to not be displayed on the upper-left hand corner, but I can't seem to find a flag that says no maximize button. This is just stylistic on my part, but why not just use a MessageBox? Other apps use one with MB_APPLMODAL when you're about to exit from them... Here's what you need to do to get your exit dialog without the max/min buttons /* Create dialog box */ g_hDlgExit = CreateDialogParam (g_hInstance, ... + SetWindowLong( g_hDlgExit, GWL_STYLE, GetWindowLong(g_hDlgExit, GWL_STYLE)~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX) ); + SetWindowLong( g_hDlgExit, GWL_EXSTYLE, GetWindowLong(g_hDlgExit, GWL_EXSTYLE)~WS_EX_APPWINDOW ); + SetWindowPos( g_hDlgExit, 0, 0, 0, 0, 0, SWP_FRAMECHANGED|SWP_NOMOVE|SWP_NOZORDER|SWP_NOSIZE ); /* Show the dialog box */ ShowWindow (g_hDlgExit, SW_SHOW); -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
I just did some runs with the commercial apps I use at work, and can see that many do *not* create custom classes or window_roles for each type of window. I think the best thing to do for the class naming is to just use an incrementing number and make each window its own class. Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. We have a GDI leak now because of this, so it will kill two birds with one stone. Under NT or later this leak shouldn't be a problem, but 95 based OSes share a common 16-bit pool amongst all apps, and may run out causing really bad things to happen if the server is running for a long time. We also have a GDI leak on the HICONs which need to be properly disposed of before they're lost completely. With a separate class per window this will be easier, since no window will share a HICON with another. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). I'll throw a patch together tonight for this unless someone beats me to it. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Custom icons per window class/name patch
Howdy, it's probably bad form to reply to your own posts but here goes: Attached is a patch from the clean test 86 release (xwin-20030518-1426.tar.bz2) The changes are as follows: * Colin's key un-sticker for when you unfocus an X window with a key depressed * Custom icons on a per-window basis - Each window created in its own class (to allow custom icon) - Class name = fn(res_name, res_class, res_role, incrementing counter) - Icon is created on-the-fly using the routines I sent before - On destroy of a window free the icon (if not x default) and class - Also still have XWIN.INI support, but seems silly to me at this point, I would just remove it completely and wait for a real ~/.xwinrc file parser and PNG files... * Set XIconSizes() to the Windows approved 16, 32, and 48. It doesn't seem to be looked at by anything, but it is in the XLib documents as something a WM should set. * Removed several misc compile warnings and turned off debug messages for GetWindowName (probably leftover from local debugging?) TBD: * KDE's proprietary icon format (it should be pretty easy to hack the present code to support it, all the real work is already done...) * Handle icon customization better, through ~/.xinitrc and PNG/JPG/etc. * Small icon bitmask problem? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com from_86.diff.bz2 Description: Binary data
RE: Custom icons per window class/name patch
Howdy Colin, At 10:52 PM 5/27/2003 +0100, you wrote: I've noticed that KDE icons have problems in their transparent backgrounds(e.g. konqueror). I suspect that the colour mask (xor) algorithm's from Earle may have a minor weakness with some pixmap sources (png's or KDE types?). I'm no expert in bit mangling graphics formats, and Earl's algorithms look tricky to me, so I'll put my hands up here. They're pretty standard and unoptimized, but since they are only called a very few times during a heavy-weight process, and for 32x32 images it's not a big deal. It just steps over the destination image, figures out which pixel in the source image that pixel maps to, and then does any color space conversions. A nicer way would be to promote all images to 32 bits and then do some 2d bilinear filtering. 8) It's sure nice to have a 1BOPS machine for under 1K$. Mind you, the icon handling is pretty impressive as it stands! I'll try and capture hicons/CreateBitmap data that goes wrong (I'm displaying 16 bit 1280x1024 incase this is device dependent?) Can you try again at 32bpp and see if things are munged? I didn't notice any problems with the quickie konqueror runs I did (over a 56k modem, you don't wanna do a long konqueror remote run, trust me) at 32bpp with the 16x16 icons. That would narrow down where to look by a lot. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
or if a window still exists that was created with the class, the return value is zero. To get extended error information, call GetLastError. Good catch, I didn't notice that. I've learned to not trust Windoze to give me an error when I do something bad, though, from much experience. The UnregisterClass() is safe to call and fail, but the DestroyIcon call isn't, and I can guarantee bad stuff if you kill an icon that's selected into a DC (or will be selected in the future for some window drawing) under older Windoze versions. We have a GDI leak now because of this, so it will kill two birds with one stone. Under NT or later this leak shouldn't be a problem, but 95 based OSes share a common 16-bit pool amongst all apps, and may run out causing really bad things to happen if the server is running for a long time. This is actually a silly concern, Windows 98 won't run long enough anyway for this to happen without a reboot. My W2K box at work, though, has an emacs that's been running for about 3 weeks so far, and I'd really hate to have my X session crap out after a long debugging session. We also have a GDI leak on the HICONs which need to be properly .. but there are many more windows with the default x icon and not with the icon of the basic application window. Fixing this means adding some stuff to deal the stuff, the Window Class concept does. I'm not sure I understand you here, but FWIW the patch sent does take care to load one copy of the X icon and never frees it, but will always free an icon in a class that's destroyed or when it is overwritten by another one. I have some questions about this: 1. Does UnregisterClass() frees the assigned ICON or has it to be free'd manually ? Nope, that's up to us. See the winDeleteWindow() function in winmultiwindow.c 2. The CreateIcon() and LoadImage() stuff does not frees the previous icon. Could this not be fixed ? Does this not fix mostly GDI leaks ? Yup, fixed but there are still the classes floating around. AFAIK that's a GDI resource too, if not then it's what's called a system resource under W95 OSes... 3. Every time a WMhints message comes in a new icon will be created. What about checking if this icon was already created and avoid every time recreating ? The pixmap id could be stored in the private window area. Possibly, but it won't save much time and if you delete the old icon you're still as good as before, with no bookkeeping needed. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). You mean canceling the wm-hints pixmap features ? That means excluding all x apps, which does provide such informations. It's still there, but the .ini file is really, really non-unix. It also uses Windoze paths and .ICO type files. IMHO what is really needed is something like a ~/.fvwmrc, with cygwin based paths and .png and .jpg support. I don*t know, what*'s was going wrong, but anyway, streching the 16x16 bit images the 32x32 for the task switcher will not give good results. KDE apps uses the _NET_WM_ICON property to provide a higher sized image. See my other mail for more informations. What's weird is that everyone says the KDE icons are 16-bit color, but when I look at the wm_hints.pixmap it's always a 24-bit color one. If they use the standard png_decompress() or whatever, that goes to RGB by default so it would make sense to leave it at 24bpp. konqueror, mozilla, and ethereal were tested... Is there anyone there who has a linux machine with KDE 3 running, which could be accessed through the internet, so that Erle could connect to this machine and try by himself ? BTW: One could use the KDE 3.1.1 release from the kde-cygwin port, but I don't know I this would be to heavy ? I'm using this for testing this icon stuff. It need some more time for starting a kde application, but with a fast machine it would be possible. I'll see if I can get this going locally, because any remote work thru my 56k modem is unpleasant to say the least. Toutefois, I think pretty much anyone should be able to put in support for the _NET_ICON format since the 24/32bpp scaler seems to be working pretty well. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Local xload for cygwin
This isn't really XWin.exe related, but I've just posted a patch to the XFree86 devel group to allow you to run xload locally under cygwin. There's no rwhod so remote doesn't work, but you can still always xload from a remote machine. Even without remote sensing it's still pretty handy and more customizable than the Windows task manager. This means when you run window managers that swallow xload into their taskbars, they work 100% under cygwin... http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=305 -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
