After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 143367 - When using "freeze panes", the rule line rendering is messed up during scrolling
When using "freeze panes", the rule line rendering is messed up during scrolling
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
1.2.x
Other Linux
: Normal trivial
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2004-05-29 20:02 UTC by Julian Lamb
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6


Attachments
Step 1 (46.75 KB, image/png)
2004-05-29 20:03 UTC, Julian Lamb
Details
Rendering bug, after scrolling to the right (46.62 KB, image/png)
2004-05-29 20:04 UTC, Julian Lamb
Details

Description Julian Lamb 2004-05-29 20:02:13 UTC
This seems to be a small rendering bug with frozen panes.

Steps:
1) Click on a cell and then freeze panes.
2) Click on the same cell (or any other cell directly to the right of the
vertical break) (see attachment 1 [details]).
3) Use the horizontal scroll bar to scroll to the right.
4) The vertical rule showing the frozen column now has a break in it, right
where the cursor used to be (see attachment 2 [details]).

Maybe a simple re-render forcing is all that is needed?

Cheers--
Comment 1 Julian Lamb 2004-05-29 20:03:45 UTC
Created attachment 28155 [details]
Step 1
Comment 2 Julian Lamb 2004-05-29 20:04:25 UTC
Created attachment 28156 [details]
Rendering bug, after scrolling to the right
Comment 3 Jody Goldberg 2004-05-31 15:16:46 UTC
Things are redrawing, but it's likely some sort of 'off by one' error in the
pixel bounds that is finally catching up to us.
Comment 4 Jody Goldberg 2004-05-31 15:31:17 UTC
ahhhh I see.  It's more subtle than that.
There's no off by one error at all.  The problem is that the edge of the cursor
is visible.  When we draw the cursor border we invert the background so that it
can be see no matter what colour it displays on.  The border line is black,
which inverts to ... white.

I've changed the line to a dark gray so that it inverts to something other than
white.  Not ideal, things still look a bit odd, but manageable.
Comment 5 Julian Lamb 2004-05-31 16:26:06 UTC
Makes sense.

I just noticed another consequence of the current rendering logic.  If the
cursor is placed on a cell directly to the LEFT of the freeze line, and you
scroll to the right, the right side of the cursor scrolls over (thus disappearing).

Is it possible to draw the cursor after the final "frozen" layout is rendered? 
Ideally, you could also restrict the cursor from being drawn only if the cell is
visible.

I know this is a trivial bug, but I have to admit it stumped me for a minute (my
mind operates on autopilot while working with spreadsheets:) ).  When I saw the
break in the freeze line, I assumed the line was a cell border and I prompty
went over there to repair it.  Even if the line changes from black to light gray
for a section, I think my initial reaction might be the same.

Cheers--
Comment 6 Julian Lamb 2004-05-31 16:39:11 UTC
BTW, OpenOffice seems to have the same issue.  Except they draw the cursor
square big enough so that it draws 1 pixel to the left of the freeze line.  When
you scroll to the right, it then leaves a nice big black line.  This is probably
even worse, since it clearly looks like a rogue cell border is left there.