Sorry for the slow response; I got attacked by busy-ness :|
On Wed, Jul 30, 2008 at 04:44:54PM +0200 I heard the voice of [EMAIL PROTECTED] via RT, and lo! it spake thus: > > When I get the chance (I'm on vacation right now), I'll send you an > annotated list of the equation results through that section of code. > My solution may just be a "workaround for stupid compilers", but at > worst, it's a harmless algebraic manipulation. I would like to see that list, when you get a change (purely out of curiosity). In the meantime, I went a slightly different way; the algebraic manipulation makes it a little less clear to read. This isn't in a critical path by any means, though, so I've made two changes that should solve it without making the calculation less clear (clearer, IMO), at a slight cost in performance.: 1) Rearrange the right side so there's no multiplying by 100 needed. Instead, we eat a floating point operation, which will be slower, but give a correct answer. I can't figure how the speed matters in the slightest. 2) Change the variables to unsigned long. On 32-bit machines, that gives us another bit of headroom; unneeded now, but good insurance. On 64-bit, we get 33 more bits of headroom, which should last a freakin' long time. (I would have just gone long, but that wouldn't help the 32's). Give this a try if you can; if it works right for you (no reason it shouldn't), and nobody has objections, I'll commit it in a few days. (patch attached, new code written inline for easy reference) if (tmp_win->OpaqueResize) { /* * scrsz will hold the number of pixels in your resolution, * which can get big. [signed] int may not cut it. */ unsigned long winsz, scrsz; winsz = tmp_win->frame_width * tmp_win->frame_height; scrsz = Scr->rootw * Scr->rooth; if (winsz > (scrsz * (Scr->OpaqueResizeThreshold / 100.0))) Scr->OpaqueResize = FALSE; else Scr->OpaqueResize = TRUE; } > I sent a patch to Richard Levitte; I can forward it to you, too, if > you like. Sending it to the list would probably be the best bet. > My only problem with it is that all the Xft fonts appear to define > rather overly generous ascent and height values that are way out of > proportion to the same measurements on equivalent X11 fonts. This may be similar to the UTF-8 issues we've seen; see the "Font sizes off in ctwm-3.8" thread (starting <http://tigerdyr.wheel.dk/ctwm-archive/1994.html>). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
# # old_revision [a8cae659665e273b3e4176d24da78ddfe0e33371] # # patch "menus.c" # from [635e0da7d75494dc138b724e180e2f8378102a2d] # to [2140619d25e517ae9b18987b93b23a1ceb281c26] # ============================================================ --- menus.c 635e0da7d75494dc138b724e180e2f8378102a2d +++ menus.c 2140619d25e517ae9b18987b93b23a1ceb281c26 @@ -2317,11 +2317,15 @@ int ExecuteFunction(int func, char *acti break; } if (tmp_win->OpaqueResize) { - int sw, ss; + /* + * scrsz will hold the number of pixels in your resolution, + * which can get big. [signed] int may not cut it. + */ + unsigned long winsz, scrsz; - sw = tmp_win->frame_width * tmp_win->frame_height; - ss = Scr->rootw * Scr->rooth; - if (sw > ((ss * Scr->OpaqueResizeThreshold) / 100)) + winsz = tmp_win->frame_width * tmp_win->frame_height; + scrsz = Scr->rootw * Scr->rooth; + if (winsz > (scrsz * (Scr->OpaqueResizeThreshold / 100.0))) Scr->OpaqueResize = FALSE; else Scr->OpaqueResize = TRUE;