Community
Participate
Working Groups
Hi everybody, I am writing an Eclipse plugin wich extends the view extension point. In the created view i want to display a very large diagram using Draw2D. The root figure is a panel and can have a size superior than 100 000. Into this panel i want to draw a polyline from the begin to the end. On a windows OS the all panel is correctly drawn. When i try to run my plugin on a Linux (Red Hat 3) plateform some part of the panel are drawn very strangely. The polyline for exemple is sometime invisible and., it is correctly drawn from 0 to 50 000 an from 60 000 to 100 000 but from 50 000 to 60 000 it is invisible. There is the same issue with the background color of the panel. Thanks Manu
Can you provide an example snippet demonstrating this problem? What version of Linux are you using? Suggestion: Is the advanced graphics turned on? i.e. have you turned on anti-aliasing. Trying turning of advanced graphics and see if the result is different. If this is the case, check the version of the Cairo library you're using. You may need to upgrade to version 2 which is available.
(In reply to comment #1) > Can you provide an example snippet demonstrating this problem? What version of > Linux are you using? > > Suggestion: > Is the advanced graphics turned on? i.e. have you turned on anti-aliasing. > Trying turning of advanced graphics and see if the result is different. If > this is the case, check the version of the Cairo library you're using. You may > need to upgrade to version 2 which is available. > Thanks for your answer, i am going to write a snippet which illustrates the problem. How can i change the Cairo library ?? I see this library into the SWT plugin but where find the version 2 and how use it , i never went into SWT's body and doesn t really know how it works... Thanks, Manu
Created attachment 44118 [details] Java class extending ViewPart wich generates the BUG This the code of the class wich extends ViewPart interface of my plugin. - On my windows workstation it results into a very large black roundedrectangle. All is fine - On my linux workstation it results into a very large black roundedrectangle but sometimes the background of the rectangle is not paint into black : it seems that this background is not painted at all. This problem occurs when we scroll over the very large rectangle. If you have any question about the snippet please let me know. Thanks Manu
Comment on attachment 44118 [details] Java class extending ViewPart wich generates the BUG This is the code of the class wich extends ViewPart interface of my plugin. - On my windows workstation it results into a very large black roundedrectangle. All is fine - On my linux workstation it results into a very large black roundedrectangle but sometimes the background of the rectangle is not paint into black : it seems that this background is not painted at all. This problem occurs when we scroll over the very large rectangle. If you have any question about the snippet please let me know. Thanks Manu
Please provide a snippet that runs as a standalone SWT application instead of a workbench view.
Created attachment 44230 [details] SWT standalone class which generates the BUG on Linux Red Hat 3 Just launch as an SWT application. - On my Windows workstation all is fine!!! - On my Linux workstation, when scrolling over the figureCanvas and so over the rounded rectangle, sometimes the black background is not visible and we can see rendering problems. Thanks Manu
Created attachment 44338 [details] SWT code to reproduce the problem
converted the client code from SWT application that use GEF figures to pure SWT code and maneged to reproduce the problem on linux. Found out the the problem will happen only if the SWT.DOUBLE_BUFFERED is set on the canvas so it seems to be a Double buffered problemin SWT Attaching the Pure SWT code required to reproduce the problem, and changing the component to SWT
(In reply to comment #8) > converted the client code from SWT application that use GEF figures to pure SWT > code and maneged to reproduce the problem on linux. > Found out the the problem will happen only if the SWT.DOUBLE_BUFFERED is set on > the canvas > so it seems to be a Double buffered problemin SWT > Attaching the Pure SWT code required to reproduce the problem, and changing the > component to SWT > Your ScrollTest class , on my linux workstation, does not reproduce the problem. Trying to add SWT.DOUBLE_BUFFERED style to the canvas does not change anything to the draw. How to reproduce this BUG with only SWT components. How reproduce the BUG ?? Have you got exactly the same BUG than me (described in previous comment) when you launch my SWT standalone class ?? What sould i do ?? Move the BUG elsewhere, or only wait for answer ? Thanks.
(In reply to comment #9) > (In reply to comment #8) > > converted the client code from SWT application that use GEF figures to pure SWT > > code and maneged to reproduce the problem on linux. > > Found out the the problem will happen only if the SWT.DOUBLE_BUFFERED is set on > > the canvas > > so it seems to be a Double buffered problemin SWT > > Attaching the Pure SWT code required to reproduce the problem, and changing the > > component to SWT > > > > Your ScrollTest class , on my linux workstation, does not reproduce the > problem. > Trying to add SWT.DOUBLE_BUFFERED style to the canvas does not change anything > to the draw. How to reproduce this BUG with only SWT components. > How reproduce the BUG ?? i'll update the SWT snippet to set the style for you, i hope this will reproduce the problem on your machine. the problem is 100% reproducable on my RHL4, and it looks exactly like the problem you descriped. (one area of the rectangle does not get drawn while scrolling using using the thumb conrol, near the middle) > > Have you got exactly the same BUG than me (described in previous comment) when > you launch my SWT standalone class ?? Yes > > What sould i do ?? Move the BUG elsewhere, or only wait for answer ? I have moved the bugzilla already to the SWT component > > Thanks. >
Created attachment 44399 [details] Pure SWT code to reporduce the problem with double buffered set
Perhaps GTK is storing two 16-bit values in a 32-bit int. You might simplify the example to simply painting a rect on a Shell in a couple of locations.
There are a couple of going on here: 1) When both SWT.NO_BACKGROUND is specified without SWT.DOUBLE_BUFFERED, then the canvas is not double buffered by GTK. This is why setting or not setting SWT.DOUBLE_BUFFERED makes a difference. Normally, all GTK widgets are double buffered unless they have only SWT.NO_BACKGROUND set. 2) gc.fillRectangle() and other graphics calls have a 16-bit limitation on X windows platforms. The line of code that fills a rectangle from "origin.x" to "width" can be changed to fill the client area (which might be faster anyways because a smaller rectangle is specified). It only appears to work when SWT.DOUBLE_BUFFERED is not specified. When the scroll bar is scrolled to the end, it should not be all red. The different failure is due to GTK double buffering code vs. X window draw calls.
We can't work around this bug. You'll need to change your code to draw only the client area.
(In reply to comment #11) > Created an attachment (id=44399) [edit] > Pure SWT code to reporduce the problem with double buffered set > Your SWT code does not reproduce the bug. To reproduce it i have to modify the Style of the canvas and the bug occurs only when SWT.No_BACKGROUND is not set!! Is it the same thing on your workstation or does the given snippet without modifications reproduce the BUG ?? I have also tried tests using Draw2D. If it works on a pure SWT application when SWT.NO_BACKGROUND is set it should also work with draw2d when the same options are set ... but it doesn't!!! Why ?? Did you tried my Snippet using Draw2d with a grey rectangle and have you got the same problem than me ?? My OS is RHL3... may be due to this ?? Thanks Manu
(In reply to comment #15) > (In reply to comment #11) > > Created an attachment (id=44399) [edit] > > Pure SWT code to reporduce the problem with double buffered set > > > > Your SWT code does not reproduce the bug. To reproduce it i have to modify the > Style of the canvas and the bug occurs only when SWT.No_BACKGROUND is not set!! > Is it the same thing on your workstation or does the given snippet without > modifications reproduce the BUG ?? > > I have also tried tests using Draw2D. If it works on a pure SWT application > when SWT.NO_BACKGROUND is set it should also work with draw2d when the same > options are set ... but it doesn't!!! Why ?? > > Did you tried my Snippet using Draw2d with a grey rectangle and have you got > the same problem than me ?? My OS is RHL3... may be due to this ?? > > > Thanks > > Manu > the problem is reproducable on my machine without modifying the snippet, I'm not usre if it had somethign to do with the fact that you are using RHL3 or not SWT team can provider more information about that. Last, yes i tried your code in GEF and it was causing the same problem
Hi all, First of all, thanks to all of you for your contributions to solve this problem. On my machine, with the pure SWT code provided by Mohammed, I can't reproduce the problem, all the figure is well displayed. To reproduce the problem, I have to modify the code by using the following style: final Canvas canvas = new Canvas (shell, SWT.DOUBLE_BUFFERED | SWT.NO_BACKGROUND | SWT.V_SCROLL | SWT.H_SCROLL) (Notice that the working one style is: SWT.NO_BACKGROUND | SWT.V_SCROLL | SWT.H_SCROLL). Manuel, do you confirm it? The first strange is that we don't have the same behaviour according to our environment. What could be the differences ? For information, we are using: Eclipse platform 3.1.1, Draw2D 3.1.1 and JRE 1.5.0, the Linux platform is RHEL3 Secondly, as the SWT code provided runs well here, we tried to pass the same style parameters to our FigureCanvas constructor that is to say: FigureCanvas canvas = new FigureCanvas(shell, SWT.NO_BACKGROUND | SWT.V_SCROLL | SWT.H_SCROLL); And with this sample, we still have the problem. Nevertheless, when we debug the FigureCanvas constructor, it calls the the Canvas constructor with same context than the SWT sample. So, we don't understand why it works with SWT and doesn't with Draw2D. There shouldn't have any differences between Draw2D and SWT but there are, does it mean that it is a Draw2D defect ?
(In reply to comment #17) > Hi all, > First of all, thanks to all of you for your contributions to solve this > problem. > On my machine, with the pure SWT code provided by Mohammed, I can't reproduce > the problem, all the figure is well displayed. To reproduce the problem, I have > to modify the code by using the following style: > final Canvas canvas = new Canvas (shell, SWT.DOUBLE_BUFFERED | > SWT.NO_BACKGROUND | SWT.V_SCROLL | SWT.H_SCROLL) > (Notice that the working one style is: SWT.NO_BACKGROUND | SWT.V_SCROLL | > SWT.H_SCROLL). > Manuel, do you confirm it? > The first strange is that we don't have the same behaviour according to our > environment. What could be the differences ? > For information, we are using: > Eclipse platform 3.1.1, Draw2D 3.1.1 and JRE 1.5.0, the Linux platform is > RHEL3 > Secondly, as the SWT code provided runs well here, we tried to pass the same > style parameters to our FigureCanvas constructor that is to say: > FigureCanvas canvas = new FigureCanvas(shell, SWT.NO_BACKGROUND | SWT.V_SCROLL > | SWT.H_SCROLL); The figure canavas will enforce the following styles (even if you are not passing them in the constructor) SWT.NO_REDRAW_RESIZE , SWT.NO_BACKGROUND , SWT.V_SCROLL , SWT.H_SCROLL > And with this sample, we still have the problem. Nevertheless, when we debug > the FigureCanvas constructor, it calls the the Canvas constructor with same > context than the SWT sample. So, we don't understand why it works with SWT and > doesn't with Draw2D. There shouldn't have any differences between Draw2D and > SWT but there are, does it mean that it is a Draw2D defect ?
(In reply to comment #18) > (In reply to comment #17) > > Hi all, > > First of all, thanks to all of you for your contributions to solve this > > problem. > > On my machine, with the pure SWT code provided by Mohammed, I can't reproduce > > the problem, all the figure is well displayed. To reproduce the problem, I have > > to modify the code by using the following style: > > final Canvas canvas = new Canvas (shell, SWT.DOUBLE_BUFFERED | > > SWT.NO_BACKGROUND | SWT.V_SCROLL | SWT.H_SCROLL) > > (Notice that the working one style is: SWT.NO_BACKGROUND | SWT.V_SCROLL | > > SWT.H_SCROLL). > > Manuel, do you confirm it? > > The first strange is that we don't have the same behaviour according to our > > environment. What could be the differences ? > > For information, we are using: > > Eclipse platform 3.1.1, Draw2D 3.1.1 and JRE 1.5.0, the Linux platform is > > RHEL3 > > Secondly, as the SWT code provided runs well here, we tried to pass the same > > style parameters to our FigureCanvas constructor that is to say: > > FigureCanvas canvas = new FigureCanvas(shell, SWT.NO_BACKGROUND | SWT.V_SCROLL > > | SWT.H_SCROLL); > > The figure canavas will enforce the following styles (even if you are not > passing them in the constructor) > > SWT.NO_REDRAW_RESIZE , SWT.NO_BACKGROUND , SWT.V_SCROLL , SWT.H_SCROLL > > > And with this sample, we still have the problem. Nevertheless, when we debug > > the FigureCanvas constructor, it calls the the Canvas constructor with same > > context than the SWT sample. So, we don't understand why it works with SWT and > > doesn't with Draw2D. There shouldn't have any differences between Draw2D and > > SWT but there are, does it mean that it is a Draw2D defect ? > Thanks. I have got an other question about which warkaround use for this bug ?? My application needs very large figures so i have to find a workaround. Is the following comment right : Using draw2d i can't draw only the client area as suggested. The painting mechanism is included into the library and don't have to be modified by the programer (and don't need to be known by the programer)... So the only solution i though is to cut my large figures into smaller figures. Is that a good idea and how could i know the limit causing the bug to be sure that it would not occured ?? Thanks Manu
That is incorrect. Using draw2d, you can limit painting to just the area that is visible. To find out what is visible to the user, you just ask the graphics for its clipping. class LargeFigure extends Figure { void paintFigure (Graphics g) { Rectangle rect = g.getClip(); rect.intersect(getBounds()); g.fillRectangle(rect); } }
(In reply to comment #20) > That is incorrect. Using draw2d, you can limit painting to just the area that > is visible. To find out what is visible to the user, you just ask the graphics > for its clipping. > > class LargeFigure extends Figure { > > void paintFigure (Graphics g) { > Rectangle rect = g.getClip(); > rect.intersect(getBounds()); > g.fillRectangle(rect); > } > > } > Thanks for your answer!!! Does it mean that by default Draw2D paints the entire figure ?? Manu
(In reply to comment #21) > (In reply to comment #20) > > That is incorrect. Using draw2d, you can limit painting to just the area that > > is visible. To find out what is visible to the user, you just ask the graphics > > for its clipping. > > > > class LargeFigure extends Figure { > > > > void paintFigure (Graphics g) { > > Rectangle rect = g.getClip(); > > rect.intersect(getBounds()); > > g.fillRectangle(rect); > > } > > > > } > > > Thanks for your answer!!! > > Does it mean that by default Draw2D paints the entire figure ?? > > Manu > I have performed some tests using your work around. it works, but instea of overriding the figure paint method causing the parent relationship of draw2d useless i overrided the fillShape method of RectangleFigure. It works fine but i still have questions: Why draw2d asks SWT to fill a very large rectangle ?? Is there any consequences when overrinding the fillShape method with the clipping of the graphics ?? What happen into the underlying ?? i.e what happened when SWT asks natively to the system to draw a line wich will be in fact unvisible or does SWT use clipping for me such as Rectangle rect = g.getClip()rect.intersect(getBounds()); ?? Thanks. Manu
> Why draw2d asks SWT to fill a very large rectangle ?? > Is there any consequences when overrinding the fillShape method with the > clipping of the graphics ?? You are just performing the same clipping that the OS is going to do anyway. The reason we don't check the clipping is that the OS always does the clipping for you, even when you do it yourself. So 99.999% of the time you are just duplicating an intersection check that will happen again. > What happen into the underlying ?? i.e what happened when SWT asks natively to > the system to draw a line wich will be in fact unvisible or does SWT use > clipping for me such as Rectangle rect = > g.getClip()rect.intersect(getBounds()); No, I think such optimization are left to the underlying OS. Also, Draw2d includes simple bounding box optimizations already. If the bounds of the figure painting a line are not inside the clip, it doesn't paint.
(In reply to comment #23) > > Why draw2d asks SWT to fill a very large rectangle ?? > > Is there any consequences when overrinding the fillShape method with the > > clipping of the graphics ?? > > You are just performing the same clipping that the OS is going to do anyway. > The reason we don't check the clipping is that the OS always does the clipping > for you, even when you do it yourself. So 99.999% of the time you are just > duplicating an intersection check that will happen again. > > > What happen into the underlying ?? i.e what happened when SWT asks natively to > > the system to draw a line wich will be in fact unvisible or does SWT use > > clipping for me such as Rectangle rect = > > g.getClip()rect.intersect(getBounds()); > > No, I think such optimization are left to the underlying OS. Also, Draw2d > includes simple bounding box optimizations already. If the bounds of the figure > painting a line are not inside the clip, it doesn't paint. > Have you seen the source of the BUG ? If i don't proceed to this clipping into my Draw2d code it leads into a BUG: bad rendering of large figure wheras the used of your sample code solves the problem. So is it safe to use such a technic (clipping by overriding paint methods) ?? Thanks for all your answers. Manu
(In reply to comment #13) > There are a couple of going on here: > > 1) When both SWT.NO_BACKGROUND is specified without SWT.DOUBLE_BUFFERED, then > the canvas is not double buffered by GTK. This is why setting or not setting > SWT.DOUBLE_BUFFERED makes a difference. Normally, all GTK widgets are double > buffered unless they have only SWT.NO_BACKGROUND set. > > 2) gc.fillRectangle() and other graphics calls have a 16-bit limitation on X > windows platforms. The line of code that fills a rectangle from "origin.x" to > "width" can be changed to fill the client area (which might be faster anyways > because a smaller rectangle is specified). > > It only appears to work when SWT.DOUBLE_BUFFERED is not specified. When the > scroll bar is scrolled to the end, it should not be all red. The different > failure is due to GTK double buffering code vs. X window draw calls. > I think i have found a work around to this bug by painting only the client area as you suggested. But i still haven t understood the real reason of the problem. Can you please tell me more about double buffered , i want to understand the source of the bug. Thanks to everybody for help. Manu
This is my last reply to this bug. There is a 16-bit limitation somewhere, period ... end of story. The workaround is safe or it would not be recommended. Please use the appropriate newsgroup for further discussion, as bugzilla is pushed out to several e-mail accounts.
Hi all, I am coming back to this bug because i ran againt into it using pure SWT code .... :o( Thanks to all of you for the previous discussions i was easily able to workaround it. I just modified my GC calls in order to only draw visible parts. It was quite easy for rectangle and lines but i am also dealing with polygons and there it was a little bit harder. Now, i am moving the "clipping" with only the visible part code directly inside an extended GC. This GC just check and intersects with the client area. It would be nice to have such a GC provided witin SWT, clients running into this OS limitation could use it as it instead of using classic GC (with of course a performance decrease ...). What do you think about it ? Thanks Manuel I
*** Bug 243618 has been marked as a duplicate of this bug. ***
*** Bug 243385 has been marked as a duplicate of this bug. ***
