Bugzilla – Full Text Bug Listing
| Summary: | Rendering Problems | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Manuel Selva <manuel.selva> | ||||||
| Component: | GEF-Legacy Draw2d | Assignee: | gef-inbox <gef-inbox> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 3.2.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Manuel Selva
Created attachment 60549 [details]
Sample to reproduce the bug
Figures that large are not supported. The OS can not paint such large rectangles, so you're seeing overflow errors. (In reply to comment #2) > Figures that large are not supported. The OS can not paint such large > rectangles, so you're seeing overflow errors. > Does it mean that SWT doesn't support it and does it mean that i can't have a root figure (a Panel) with a background color and an XYLayoutManager exceding a given size ? It means that if you want to fill a rectangle, don't fill one that is larger than the clipping area that is being painted. So, you'll need a special rectangle figure that doesn't paint so far outside the Graphics.getClip(). Instead of: graphics.fillRectangle(getBounds()); do: Rectangle rect = getBounds().getCopy(); rect.clip(graphics.getClip()); graphics.fillRectangle(rect); Or maybe you could extend SWTGraphics to do the clipping in general? Thanks for your answer,
I tried the following overriding of RectangleFigure
public void fillShape(Graphics g) {
Rectangle rect = g.getClip(new Rectangle());
rect.intersect(getBounds());
g.fillRectangle(rect);
}
but still have rendering problems
Created attachment 60649 [details]
Sample class reproducing the bug with an extended rectangle figure
In this sample the method fill shape of rectangle is overrided to only fill the intersection between the figure bounds and the graphics clipping.
Using this solution doesn't work since there is always rendering problems when scrolling to the right with the thumb and then coming back to the left with the left arrow of the scroll bar.
Is my fill method wrong or is there any problem inside draw2d graphics or inside figureCanvas.scrollToX ?
Thnaks
Manuel Selva
(In reply to comment #2) > Figures that large are not supported. The OS can not paint such large > rectangles, so you're seeing overflow errors. > Where is exactly the limitation of "large figure" ? The limitation I'm guessing is in GDI. I think that it combines two 16-bit integers into one 32-bit argument, but I'm just speculating. That would mean, anything larger than 32,000 (unsigned) or 16,000 (signed) wouldn't draw properly. And, this is different on each OS. SWT gives you the platform limitations, it doesn't circumvent them. Nor does draw2d. The snippet you've created is helpful, but it would help more if you set the viewport to the location that is failing, so that no manual interaction is required to debug the issue. FYI, I am no longer employed to work on GEF, but I attempt to contribute in my "personal" time (e.g., instead of playing foosball :-), or as my new job occasionally requires. Manual, could you create a FAQ entry on this for GEF? I meant "Manuel" (In reply to comment #9) > Manual, could you create a FAQ entry on this for GEF? > Thanks for your quick answer Randy (instead of playing football). Yes i'll create an entry in the GEF FAQ. But still have one question: my Snippet is useful ? Useful to see the limitation but not to know how to workaround it ... and i need to find a workaround! Does the workaround consisting in paint the intersection between my rectangle and the graphics clipping solve the problem on your computer ? It doesn't solve it on my .. when is scroll using the left arrow i got a lot of "vertical lines" not painted at all in my figure. It seems that Draw2D scrolling and Draw2D SWTGraphics have some strange behavior. For example replacing canvas.redraw(expose) by canvas.redraw() in the scrollToX method of FigureCanvas class fix this bug (I know that is not THE solution but may be can help to understand what happened). Manuel Hi all, After some research i am always wondering how to solve this bug. The solution consisting in only draw the "visible part of the rectangle" (intersection with clipping) doesn't work. It seems that there is a lot of 16 or 32 bit limitations inside SWT and as a consequence inside draw2d. For example in my sample application (see last attachement) the 16/32 bits limitations is avoided for the gc.fillRectangle graphical call but this limitation must remain somewhere in the apps since the rendering is bad. May be this come from Transform transform field inside SWTGraphics class ... ? I am right ? I really appreciate a work around for this but it seems to be impossible to have a draw2d application which root figure's bounds exceed a certain XX size. Has anybody encountered the same problem ?? Thanks Manuel Yes, on the newsgroup, there have been a couple of other cases of people running into rendering problems for very large diagrams. You can create an SWT-only snippet and ask on the SWT newsgroup if you want to pursue this further. But like Randy suggested, you might be hitting the platform limitations here. Several month ago i posted a bug concerning large figure rendering problems. After several discussions SWT team (Steve Northover) told that there is a 16 bit limitations for graphical calls on X plateform. OK. But this time the bug i am having is also visible on Windows and can't be reproduced only using SWT. Have you got any idea to reproduce it using only SWT and before this, have you reproduce it on your platform ? Thanks Manuel Selva (In reply to comment #9) > Manual, could you create a FAQ entry on this for GEF? > Entry created in GEF FAQ. |