On 3 Oct 2006, at 14:58, Fred Kiefer wrote:
Even after all the backend window changes I still have problems when
resizing a window. The reported error is:
2006-10-03 15:50:15.860 GSTest[25446] X-Windows error - BadValue
(integer parameter out of range for operation)
on display: :0.0
type: 0
serial number: 669
request code: 143
<snip>
The traceback is meaningless unless X communications are
synchronised ... my guess is that the error applies to an earlier
attempt to wriite a shared memory buffer.
This happens with the art backend, the xlib and the cairo backend both
resize without an error, which is quite surprising for me. I use KDE
with the default window manager (kwin ?) running under SuSE Linux
10.1.
Yes this is with an updated GNUstep from today.
I did some work trying to eliminate flushed due to expose events
causing bad access to shared memory buffers ... but I was not
convinced the changes worked, and they made things far too slow
(passing expose events through the event queue to the gui and sending
flushes back to the backend really killed window dragging
performance), so those changes are currently disabled.
I've just (ie a dew minutes ago) added a hack to the code in svn
which just attempts to clip any rectangle passed to the flushing code
so that it can't attempt to flush anything not actually in the
buffered rectangle. This obviously won't fix the underlying problem,
but it should (I hope) stop the X errors. Please let me know.
Cheers
Fred
PS: Why does "openapp ./GSTest" work but for debugging I have to
specify
"debugapp ./GSTest.app". Without the file extension gdb complains it
cannot find the program.
I don't know ... never use debugapp ... but I would guess it's a
transient problem with Nicola's simplification of the make system to
remove the differentiation between normal, debug, and profile
applications.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev