Charles Philip Chan <[EMAIL PROTECTED]> writes:
> and here is the backtrace:
>
> (gdb) backtrace
> #0 0x408cf437 in _pixmap_combine_alpha (context=0x824aba8,
> source_im=0x8451dd0, source_alpha=0x8502df8, dest_im=0x82fef78,
> dest_alpha=0x8502e18, srect={x = 0, y = 0, width = 253, height = 188},
> op=NSCompositeSourceOver, drawMechanism=XGDM_FAST32, fraction=1)
> at XGBitmap.m:153
> #1 0x408e15cf in
> _i_XGGState___compositeGState_fromRect_toPoint_op_fraction_ (
> self=0x82fddf8, _cmd=0x409143b0, source=0x82fe9d8, fromRect={origin = {
> x = 0, y = 0}, size = {width = 253, height = 187.942856}}, toPoint={
> x = 2, y = 23.5285721}, op=NSCompositeSourceOver, delta=1) at
> XGGState.m:599
[Note the above is reformatted and abbreviated]
Ok, I this bug is most probably caused by the fact that the
height is rounded up from 187.942856 --> 188.
The following patch will always round the size of the
rectangle down. So, if you can reproduce the crash, could
you check if this patch fixes it?
DISCLAIMER: I have not been able to reproduce this crash,
also, changing this rounding code might introduce
some problems in other circumstances.
But the rounding issue is actually not dealt with at all
in a satisfactory way. The rounding functions that are
now in place are an attempt to make the rounding more explicit.
So basically, when you deal with non-integer coordinates
it might not work.
Initial testing by my does not show any problems with
this patch. But it should be tested.
2002-01-26 Willem Rein Oudshoorn <[EMAIL PROTECTED]>
* xgps/Headers/gnustep/xgps/XGGeometry.h (XGWindowRectToX): simpler algorithme
for determining size result. This one is stable with respect to the origin.
added explanation in comment.
Index: Headers/gnustep/xgps/XGGeometry.h
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/xgps/Headers/gnustep/xgps/XGGeometry.h,v
retrieving revision 1.1
diff -c -r1.1 XGGeometry.h
*** Headers/gnustep/xgps/XGGeometry.h 21 Nov 2001 03:35:32 -0000 1.1
--- Headers/gnustep/xgps/XGGeometry.h 26 Jan 2002 22:47:46 -0000
***************
*** 154,160 ****
an appreciable difference on speed - will it ? */
static inline int gs_floor (float f)
{
! if (f >= 0)
{
return (int)f;
}
--- 154,160 ----
an appreciable difference on speed - will it ? */
static inline int gs_floor (float f)
{
! if (f >= 0.0)
{
return (int)f;
}
***************
*** 162,168 ****
{
int g = (int)f;
! if (f - ((float)g) > 0)
{
return g - 1;
}
--- 162,168 ----
{
int g = (int)f;
! if (f - ((float)g) > 0.0)
{
return g - 1;
}
***************
*** 189,207 ****
return newPoint;
}
static inline XRectangle
XGWindowRectToX (XGGState *s, NSRect r)
{
XRectangle newRect;
newRect.x = gs_floor(r.origin.x + s->offset.x);
! /* We gs_floor the extreme points, and get the width as the difference */
! newRect.width = gs_floor(r.origin.x + s->offset.x + r.size.width)
! - newRect.x;
!
newRect.y = gs_floor(s->offset.y - r.origin.y - r.size.height);
! newRect.height = gs_floor(s->offset.y - r.origin.y) - newRect.y;
!
return newRect;
}
--- 189,221 ----
return newPoint;
}
+ /*
+ * Convert NSRect to XWindow rectangle. This means that there are
+ * two conversions needed.
+ *
+ * 1 - flip vertically
+ * 2 - round to integer coordinates.
+ *
+ * The problem is is in the rounding.
+ * At the moment we round the origin down to the nearest integer.
+ * (The rounding is done in X-coordinates)
+ * The size is also rounded down.
+ *
+ * an older implementation (26 Jan 2002) rounded the corner coordinates
+ * down. This had the disadvantage that the resulting size
+ * depends on the origin of the rectangle r.
+ */
static inline XRectangle
XGWindowRectToX (XGGState *s, NSRect r)
{
XRectangle newRect;
newRect.x = gs_floor(r.origin.x + s->offset.x);
! newRect.width = gs_floor (r.size.width);
!
newRect.y = gs_floor(s->offset.y - r.origin.y - r.size.height);
! newRect.height = gs_floor (r.size.height);
!
return newRect;
}
