When I open Clouseau and expand what I'm inspecting so that it goes off the screen, I see gray regions if I scroll to the right or down. Here's a screenshot:
http://www.ece.iastate.edu/~pjscott/inspector-bug.png
I got that just by doing (clouseau:inspector *features*) and scrolling to the right. The same problem occurs at the bottom if I inspect something too long to properly display. If I scroll down in the previous window:
http://www.ece.iastate.edu/~pjscott/inspector-bug2.png
This is annoying, and I don't know enough about the internal workings of McCLIM to know where to start fixing it. I think it might be related to this code:
(defmethod redisplay-frame-pane :after ((frame inspector) (pane application-pane) &key force-p) (declare (ignore force-p)) (change-space-requirements pane :height (bounding-rectangle-height (stream-output-history pane))))
...but I'm not sure, and I don't want to just randomly munge code and hope that I accidentally fix the problem.
--Peter
I think that the gray area problem is probably not a clouseau problem, per se. I have had it on and off with other panes with incremental redisplay (do you have incremental redisplay?) and scrolling.
best, R
FWIW, I think that the problem has to do with the fact that the space requirement changes don't work properly with scrolling panes (which have internal and external space requirements to manage). I looked into this a while ago, but I never understood the space-requirements code well enough to fix it.
R
Peter Scott sketerpot@gmail.com writes:
When I open Clouseau and expand what I'm inspecting so that it goes off the screen, I see gray regions if I scroll to the right or down. Here's a screenshot:
You all were on the wrong track ...
First off, the pane hierarchy in the Clouseau application is a little strange: The stream pane is inside a border pane inside a vrack pane inside a viewport inside the scroller pane. You would get a saner hierarchy by saying :scroll-bars t in the definition of the 'app' pane and skip the scrolling in the layout.
Anyhow, still there is a bug.
After looking into it, I saw that space requirements are fine. The space requirements of the stream are properly distributed up to the scroller pane, which you can also see in the correct min/max/thumb-size values of the scroll bar.
I looked at the sheet regions and transformations and they all looked perfectly fine. Then I investigated actual sheet geometry as the X server believes. And there is our bug: The X server disagrees with CLIM!
So the defect is in the coordinate swizzling code of mine. The documentation string of UPDATE-MIRROR-GEOMETRY, which is the function responsible for synchronizing the sheet geometry to the X server, states:
| [...] This function is supposed to be called whenever one of the | following happens: | | [...] | - the parent's native transformation changed | - the parent's transformation changed | - the parent's mirror region changed
And exactly these are the cases, we miss.
Doing
(defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet) + (mapc #'update-mirror-geometry (sheet-children sheet)))
seems to help.
For completeness we also should do:
(defmethod note-sheet-region-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet) (mapc #'update-mirror-geometry (sheet-children sheet)) )
This should be regarded as a temporary fix, since IMHO UPDATE-MIRROR-GEOMETRY itself should decide when to update the native region or transformation of a child of a sheet.
Gilbert Baumann gilbert@base-engineering.com writes:
Doing
(defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet)
- (mapc #'update-mirror-geometry (sheet-children sheet)))
seems to help.
Does this recurse all the way down the hierarchy, or does it stop at the first generation of children?
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
Gilbert Baumann gilbert@base-engineering.com writes:
Doing
(defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet)
- (mapc #'update-mirror-geometry (sheet-children sheet)))
seems to help.
Does this recurse all the way down the hierarchy, or does it stop at the first generation of children?
It should recurse all the way down, so it might have ugly performance implications. We might however stop recursion as soon as nothing changes.
I noticed another ugly thing: Suppose a sheet S with its region SR and its transformation T within a viewport V with region VR. UPDATE-MIRROR-GEOMETRY works by recognizing that only
(SR o T) ^ VR
is potentially visible. For example say the sheet S is 1000 pixel height and the viewport is 100 pixels high. Further suppose S is scrolled so that y=200 in S maps to y=0 in V. Then the potentially visible y range (in S) is only [200, 300) so the mirror region of S is actually set to something 300 pixels high.
Now you scroll a bit, making y=210 in S mapping y=0 in V. The potential visibile y range now is [210,310) leading to a mirror region 310 pixels high. In this case scrolling will actually resize the mirror.
That is UPDATE-MIRROR-GEOMETRY is not clever enough to recognize, that it could make the mirror region larger [and here actually up to the orignal size] and thus avoid resizing on scrolling. If it were smart enough it could even lead to allocating an even larger mirror region of saying 2000 pixels high (in contract to the 1000 high sheet region) and thereby avoiding resizing the sheet in case more content is spilled to S. E.g. if S is a stream pane and you output a couple more lines.
-
Christophe Rhodes -
Gilbert Baumann -
Peter Scott -
rpgoldman＠real-time.com