-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make ScaledGraphics optional #106
Comments
The We encountered this in our RCP app: And other discussions: https://bugs.eclipse.org/bugs/show_bug.cgi?id=470334 I don't know whether the underlying cause of the font problem could be fixed or whether |
And another RCP tool, Modelio, made the same decision
|
One downside of not using ScaledGraphics: |
In the 4diac IDE we also replaced the scaled graphics with the graphics [1]. Since then I have the impression the graphics looks nicer under Linux however we also noticed some problems:
As for both windows was mostly affected it could also be an SWT issue. Although for us it is clear that we stay with the non scaled version. But as there is a downside I think the optional proposal by @Phillipus sounds like a good idea. |
This issue is stale because it has been open for 90 days with no activity. |
I'll be submitting a draft PR for discussion soon. |
@Phillipus thanks for the pullrequest. I think it is a very good starting point and much better what we did in Eclipse 4diac. However I still think there are some issues, which I'm not sure how to solve:
BTW is it good to discuss the this here or better at the PR? |
@azoitl Thanks for looking at the PR.
This is in class Because the
That won't work. The code in
Good point. Should there be getters, too?
I think here is best, as it is permanent whereas a PR might change or be abandoned. |
I got that and understood why. Given my experience with other changes I just wanted to raise a concern. I also have no idea for a better solution.
I played around a bit today in the morning. Nothing that made my happy but I see your changes a chance to move at least some duplicated things to ScalableFigure.
I would say yes, because this would enable more stuff to be moved to ScalableFigure. Especially when we define that getters and setters there. Also for the scale factor.
Good point. |
@Phillipus today I finally found some time to play with your PR. See my PR #135 for some results. By introducing a common interface for both ScaleableLayeredPane and ScaleableFreeformLayeredPane I could move some common code to this interface. Not sure if it is the best approach but wanted to get your opinion on it. I also tried it out with the LogicEditor example. My first test case for new things. There I noticed that my comment with the setters is most probably not needed. Would even make the useScaledGraphics final now. As the API tools are not very happy about the PrinterGraphics changes I think we should split up the changes in separate parts. |
Hi @azoitl - thanks so much for taking this further.
Well, it certainly is a better approach! I think we should continue this way. As for |
Hi @Phillipus today one of our users ran into a problem that seems for me related to this one. We noticed that our diagrams are not scaling correctly on Windows when a display zoom is set. In our case the user had a display zoom of 125%. All Eclipse widgets correctly get scaled. However the GEF drawings are still at the same size. However the fonts in the GEF drawings are scaled with the display scale factor. We are not using the scaled graphics as proposed by you. But we use sofar a very ugly workaround. Have you had some similar issues. Is this related to the scaled graphics problem or something else? |
Hi @azoitl I'm not sure if it's the same issue but I discovered many years ago that a font for a Draw2d So I created a method to convert a given font to a scaled font that can be applied to an private static FontRegistry windowsFontRegistry = new FontRegistry();
public static Font getAdjustedWindowsFont(Font font) {
if(font != null && PlatformUtils.isWindows()) {
int DPI = font.getDevice().getDPI().y;
if(DPI != 96) {
FontData[] fd = font.getFontData();
String fontName = fd[0].toString();
if(!windowsFontRegistry.hasValueFor(fontName)) {
float factor = (float)96 / DPI;
int newHeight = (int)(fd[0].getHeight() * factor);
fd[0].setHeight(newHeight);
windowsFontRegistry.put(fontName, fd);
}
font = windowsFontRegistry.get(fontName);
}
}
return font;
} |
Hi @Phillipus, Top is 100% bottom 125% native scaling. |
@Phillipus after we have the main classes configurable I started to look at the Thumbnail. Here I noticed two three things:
While the last thing is IMHO a quick win. I'm less sure about the first 2. |
TBH I wonder if the |
@Phillipus not sure if I could come up with a better version on rewrite. I did some experiments which made it worse. So at least I know how to do that. With that we may learn enough how to proceed with it. |
With the fix for the thumbnail in PR #198 we are nearly there. The only open point of I correctly remember is to fix the printing. Not sure yet how to do this. Any suggestions are warmly welcome. |
PR can be used as a starting point, please feel free to make any changes... |
Thx, will have a look in the next days. |
This issue is stale because it has been open for 90 days with no activity. |
This issue is stale because it has been open for 90 days with no activity. |
This issue is stale because it has been open for 90 days with no activity. |
Opening this issue as a placeholder for discussion about the
ScaledGraphics
class and making it optional, why it has problems, and what we can do about it.More to follow...
The text was updated successfully, but these errors were encountered: