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;
