Community
Participate
Working Groups
public class Bug3 { static Display display = new Display (); public static void main (String [] args) { Shell shell = new Shell (display); Canvas canvas = new MyCanvas(shell); canvas.setSize(100,100); shell.pack(); shell.open(); // Main loop while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose(); } static class MyCanvas extends Canvas { MyCanvas(Composite parent) { super(parent, SWT.NONE); // set up listeners addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { drawLine(e.gc, 0, 1); drawLine(e.gc, 1, 1); drawLine(e.gc, 2, 1); drawLine(e.gc, 3, 1); drawLine(e.gc, 6, 4); } private void drawLine(GC gc, int y, int width) { gc.setLineWidth(width); gc.drawLine(0, y, 50, y); } }); } } }
This bug still exists - any chance it'll be fixed soon?
I actually think this is the right behavior, but I need to investigate a bit more. When the line width > 1, GC.setLineCap() determines how line caps are done. The default line caps is SWT.CAP_FLAT, which means that the end caps of the line are butt with the specified points. So it does not make sense to add an extra pixel to the line length. If you change the line caps to SWT.CAP_SQUARE, you might get what you want. Anyways, I will investigate more, but my inicial position as that there will not be any changes here.
Why should lineCap only apply when the width is greater than one? If it makes sense to shorten the line of width 2, it should also shorten the line of width 1. At least this surprising logic ought to be documented.
I agree with comment #3 - when the line cap is set to SWT.CAP_FLAT (the default; no cap), the rendered length of the lines should be consistent, regardless of how thick the line is. When using other line caps, then sure, they might add a little more/less to the end based on how thick the line is (to make the cap style look right). But with no cap, lengths should be the same.
I did a bit more digging into this issue (it's an important one for us): When drawing a width-1 line from (10, 0) to (15, 0), it covers 6 pixels across: 10, 11, 12, 13, 14, 15. This should be the desired behaviour. However, when doing the reverse - from (15, 0) to (10, 0), it covers only 5 pixels: 10, 11, 12, 13, 14. If the GC has alpha set on it however, both of the above results in the desired behaviour - a line 6 pixels long, including both the end points. If the line has width > 1, it always results in the line being one pixel short on the same side: it doesn't cover pixel # 15. I think the two issues may be closely related, so I mention it here - let me know if I should submit a separate bug.
It looks like the lines in GC.drawLine: OS.MoveToEx (handle, x1, y1, 0); OS.LineTo (handle, x2, y2); if (data.lineWidth <= 1) { OS.SetPixel (handle, x2, y2, OS.GetTextColor (handle)); } are related to this issue - if the OS.SetPixel line is removed, the line is short both ways, and always on the same side. Seems that OS.LineTo doesn't include the end pixel when going from left to right or top to bottom, and doesn't include the beginning pixel when going from right to left or bottom to top. When drawing the line with Gdip (invoked when the line has alpha) there is no difference in right-to-left vs left-to-right, but there is still the issue where thicker lines are short by a pixel (on the right or bottom).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
