Community
Participate
Working Groups
The SWT GC should support rendering hints on the GC. By documenting these as "hints" application developers are free to take advantage of better graphics support on platforms that have them, and on platforms that don't, the graphics will degrade in an acceptible fashion to the platform defaults. For example, Windows will support anti-aliased lines, elipses, fills, etc. Also, you can change the mitre of lines and polylines. This should be exposed in SWT. In my current project, I am debating whether I should use Images to cache the desired anti-alised appearance, and render the antialiasing myself. Or I might store a few decorations as Images because I cannot paint those decorations the way I would like. The end result is that I am going to use more Image handles.
I would like this to be higher priority. It seems like an easy thing to make available on windows, and have its behavior be "optional" on other platforms.
Created attachment 420 [details] Example usage of antialiasing
Some applications that are using arcs (spetially with caps) and lines intensively looks simply unacceptable without antialiasing. Very low-level algoritm implementation to solve this problem in application that uses high level framework looks srtange, and better to have this support included in SWT.
A GEF user has posted a working version of the win32 GDIPlus support to the GEF newsgroup. Search for the post titled "GDI". Not all win32 boxes have the GDIPlus DLL, so SWT would have to detect this and ignore the rendering hints when not available.
changing severity since this is important to a lot of people, and there is no workaround for clients of SWT.
Sorry but "higher quality graphics in SWT" didn't even make it as a deferred item on the Eclipse 3.0 plan. Could OpenGL be used instead?
That's unfortunate. There are only 9 SWT bugzillas with 3 or more votes.
I downloaded the zip file posted on the GEF newsgroup under the topic "GDI+. Logic example with antialiasing (big)" and I followed the instructions posted in that topic to the letter; but I didn't manage to see any antialiasing in my plugin or the Logic plugin for that matter. I do have gdiplus.dll in my system path, I'm using Windows 2000 and I used the suggested command line. I tried this out with eclipse 2.1.1, 2.1.2 and 3M2. I would really really love to see my GEF plugin anti-aliased; we have a non GEF version (using Win32 API) which my plugin has replaced; but the dated application still looks much better because it antialiases the figures. I still need to put in arcs on my connections and I imagine those will look pretty bad without antialiasing.
*** Bug 52602 has been marked as a duplicate of this bug. ***
I've looked all over the GEF newsgroup for the posting mentioned here. Is there anyway someone can repost it or attach the patch to this bug?
23 votes and still P4
We have added support for line CAP and JOIN (>20041116). See GC.setLineCap() and GC.setLineJoin().
Requested (from Morten Moeller) GDI+ posting: http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg01709.html
Created attachment 16549 [details] gdiplus.zip from newsgroup
Created attachment 16893 [details] Native part of GDIplus Graphics Here are the sources for the native part.
Is there any chance this bug is targeted for 3.1? There is no workaround so it's very important for clients.
Antialising and interpolation hints are items for the 3.1 M6 milestone. We have been working on this as part of the new advanced graphics API. It is very hard to come up with an API that is reasonable for all the platforms/libraries we are working with: GDI+, Cairo and Quartz. On Cairo, currently there is no API to control if antialiasing is applied or not. Output is aways antialised. On GDI+, it is possible to control if antialising is applied separately for lines/curves and text. There are also different algorithms (it is not only an ON/OFF property). On Mac, antialising is a ON/OFF property. The same goes for interpolation (image quality/speed hint). There are different algorithms available on different platforms.
I think image interpolation is a separate enhancement. GTK and Motif are basically ignores since you can't do anything anyway. On the Mac you could emulate the GDI+ behavior. Turn on/off global AA based on the type of graphics call being made. Or, you could provide a bunch of hint styles which may or may not have an effect, or may conflict with each other (Sounds pretty bad) Or, just provide a single setting which affects as many operations as the platform supports. Clients could turn this setting on and off based on what they are painting. Which way are you leaning? It would be nice if Fonts were not affected. SWT currently renders using ClearType(TM) if enabled. I would not want AA to override clear type, making fonts harder to read. (Or is clear-type one of the available AA-algorithms?) Also, what does AA do when printing?
Can someone update me on the current state of this. Is there any provision for this functionality in M6 and how do we take advantage of it? Thanks. James
Code did go into M6, but check GC.setAntialias() in HEAD.
Fixed in HEAD. See GC.setAntialias() and GC.setTextAntialias().
What is the behavior of calling this API if Cairo is not present?
When drawing rotated text, it is desirable to enable Gdip.TextRenderingHintAntiAliasGridFit rather than Gdip.TextRenderingHintClearTypeGridFit ClearType only does antialiasing in the horizontal direction when using LCD or Trinitron monitors. I think more styles are needed for setTextAntiAlias.
Created attachment 19916 [details] default vs cleartype on rotated text
Are there any example code snippets that use the new API?
