Bug 370989

Comment 1 Remy Suen 2012-02-08 13:38:42 EST

Hi Thomas, thank you for your bug report. I am able to reproduce the problem with a pure SWT snippet actually. I do not see the problem you describe when regularly using the SDK though.

If you open the 'Package Explorer', scroll to the bottom, open the search dialog with Ctrl+H and close it, the view is still okay, right?

Comment 2 Remy Suen 2012-02-08 13:39:33 EST

(In reply to comment #0)
> I put breakpoints in Table.showItem, and other points that
> looked like repositioning and found that the rendering engine does some stuff
> when setting the font but sets it back to the original position.

When we set the font to the table, please attach the call stack to this bug, thanks.

Comment 3 Remy Suen 2012-02-08 14:39:28 EST

I opened a bug against SWT for the simple case, see bug 370997.

Comment 4 Thomas Kratz 2012-02-09 04:04:12 EST

Created attachment 210781 [details]
stacktrace from setFont

I don't think this is the problem as the topIndex gets restored afterwards and the actual repositioning seems to happen somewhat later (at least from my visual impression) But I'm just guessing.

I don't see this in the SDK, but I see it at different situations in my app.
To the stacktrace: My codebase is a little outdated, the line numbers are from 4.1M7 build.

Comment 5 Remy Suen 2012-02-09 06:09:57 EST

(In reply to comment #4)
> I don't think this is the problem as the topIndex gets restored afterwards and
> the actual repositioning seems to happen somewhat later (at least from my
> visual impression) But I'm just guessing.

If you comment out the setFont(*) call in CSSPropertyFontSWTHandler, then you don't have any scrolling problems, correct?

Comment 6 Thomas Kratz 2012-02-09 08:50:39 EST

Yep thats right.

Comment 7 Remy Suen 2012-02-09 08:54:34 EST

What does your CSS file look like? Do you have multiple CSS files? Could you attach them here? Perhaps it can be used to try to reproduce your problem since the SDK doesn't seem to exhibit this problem.

Comment 8 Thomas Kratz 2012-02-09 09:03:58 EST

Created attachment 210799 [details]
css that makes the trouble

Slightly modified CSS at my side.

Comment 9 Remy Suen 2012-02-09 09:05:47 EST

(In reply to comment #8)
> Created attachment 210799 [details]
> css that makes the trouble

I guess your first definition is probably the problem.

> CTabItem, Label, Tree, Text, Combo, Table {
> 	font-family: "Arial";
> }

Comment 10 Thomas Kratz 2012-02-09 09:07:40 EST

Yep! Thanks so far. I'll fall back to default Table font until this gets fixed. I had some complaints from users with really long table results... But now I can work around at least.

Comment 11 Remy Suen 2012-02-09 09:28:19 EST

Hi Thomas, I can reproduce the problem. It seems to only affect Tables which is why we don't see it in the 'Package Explorer' (since that is a Tree).

I think we can mark this as a duplicate of bug 370997, what do you think?

Comment 12 Thomas Kratz 2012-02-09 09:29:28 EST

Ok. As always: Thanks for your support.

Comment 13 Remy Suen 2012-02-09 09:37:50 EST

(In reply to comment #12)
> Ok. As always: Thanks for your support.

No problem, Thomas.

We could workaround this on the CSS side by checking whether the fonts are equal before we set it but I'll check with the SWT people to see what they think first. I'll leave this bug open in the meantime.

Comment 14 Remy Suen 2012-02-09 11:18:46 EST

Thomas, I will mark this bug as a duplicate. If you'd like to keep the Arial font, you could change the code of the handler to check the font before setting it. I will talk to the SWT team to try and get bug 370997 fixed.

private static void setFont(Widget widget, Font font) {
	if (widget instanceof CTabItem) {
		((CTabItem) widget).setFont(font);
	} else if (widget instanceof Control) {
		Control control = (Control) widget;
		FontData[] setData = font.getFontData();
		FontData[] currentData = control.getFont().getFontData();
		if (setData.length != currentData.length) {
			control.setFont(font);
			return;
		}

		for (int i = 0; i < setData.length; i++) {
			if (!setData[i].equals(currentData[i])) {
				control.setFont(font);
				return;
			}
		}
	}
}

*** This bug has been marked as a duplicate of bug 370997 ***