> b) ___Gamma Curve data is corrupted.___
> When turning on table-based gamma correction (and thus instantiating the
> gamma curve widget), the following happen:
> o correct values are read from the (microtek) backend, so far so good.
> o immediately after the call to gtk_curve_set_gamma in curve_new(),
> a call to gtk_curve_get_gamma reveals the correct values were
> written to the widget.
> o sometime later (when the event loop updates/displays the widget, I
> imagine), xscanimage declares
I already have seen this, too. I hope I will find the time to take a closer
look at it soon!
Hi Oliver, et al.,
For no good reason, I went poking at this with gdb (well, at least I'm
learning how to use gdb), and made some discoveries. The problem is in
the widgets, not xscanimage. Someone who knows more about GTK widget
programming will need to take over from here....
When xscanimage runs, the corruption to the gamma curve widget happens
during the call to gtk_widget_show(notebook) at the end of vector_new()
["gtkglue.c"]. Here are before and after snapshots of the Curve:
BEFORE:
$36 = {graph = {widget = {object = {klass = 0x809b578, flags = 67328,
ref_count = 1, object_data = 0x8087690}, private_flags = 0,
state = 0 '\000', saved_state = 0 '\000', name = 0x0, style = 0x8084368,
requisition = {width = 262, height = 262}, allocation = {x = -1, y = -1,
width = 1, height = 1}, window = 0x0, parent = 0x809b308},
draw_data = 0x0}, cursor_type = 132, min_x = 0, max_x = 255, min_y = 0,
max_y = 255, pixmap = 0x0, curve_type = GTK_CURVE_TYPE_FREE, height = 255,
grab_point = -1, last = 0, num_points = 256, point = 0x809ba48,
num_ctlpoints = 2, ctlpoint = 0x809ba30}
AFTER:
$37 = {graph = {widget = {object = {klass = 0x809b578, flags = 329664,
ref_count = 1, object_data = 0x8095660}, private_flags = 0,
state = 0 '\000', saved_state = 0 '\000', name = 0x0, style = 0x809d5f8,
requisition = {width = 262, height = 262}, allocation = {x = -1, y = -1,
width = 1, height = 1}, window = 0x809d3d8, parent = 0x809b308},
draw_data = 0x0}, cursor_type = 132, min_x = 0, max_x = 255, min_y = 0,
max_y = 255, pixmap = 0x809d960, curve_type = GTK_CURVE_TYPE_FREE,
height = -5, grab_point = -1, last = 0, num_points = -5, point = 0x809d540,
num_ctlpoints = 2, ctlpoint = 0x809ba30}
Note how "height" and "num_points" are now the unlikely values of -5, and
the "point" vector has moved.
The basic problem is that "allocation.width" and "allocation.height" are 1,1
and not 262,262. The chain of events (I believe) is: [in "gtk/gtkcurve.c"]
gtk_curve_graph_events() is called for either a CONFIGURE or EXPOSE event,
and subsequently calls gtk_curve_draw() with the width and height taken
from the "allocation", as:
width = w->allocation.width - RADIUS * 2;
height = w->allocation.height - RADIUS * 2;
i.e. -5 and -5
gtk_curve_draw() sees the requested width,height (-5,-5) doesn't match what
was loaded into it (256,256), and calls gtk_curve_interpolate(), which then
generates screwy numbers.
SO: Perhaps gtk_curve_graph_events() should use the curve's "requisition"
instead of its "allocation" to calculate those width and height.
Perhaps in an earlier incarnation of GTK, the curve widget got 'allocated'
earlier or something.
I don't really know what design issues are involved here.
Whatever the solution is, I'd love to hear it, just to get some more insights
into the workings of GTK.
Hope this is a good head-start,
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com