Community
Participate
Working Groups
I have run a simple test multiple times: for (int i = 0; i < 20000; i++) { event.gc.drawString("0123", 0, 0, true); } Both on Mac OS X 10.10.2 and Windows XP SP3. The swt versions: Mac: org.eclipse.swt.cocoa.macosx.x86_64_3.103.1.v20140903-1947.jar Windows: org.eclipse.swt.win32.win32.x86_3.7.2.v3740f.jar The difference in time is huge, the Mac version being 47 times slower! This makes SWT completely unusable for text drawing applications on Mac.
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. -- The automated Eclipse Genie.
We also see performance drops on macos versions, are there any plans to investigate this?
I definitely notice on macOS that the performance tanks when more text is on the screen. This could potentially be the cause of it.
The same issue here. We need to draw hundreds of strings on screen and it is terribly slow on MacOS while it is fine on Windows or GTK. I did some profiling. GC.drawString and GC.textExtent are the main problems. GC.drawText most CPU consuming calls: (~90% of time) org.eclipse.swt.internal.cocoa.NSLayoutManager.glyphRangeForTextContainer org.eclipse.swt.internal.cocoa.NSLayoutManager.drawGlyphsForGlyphRange org.eclipse.swt.graphics.GC.createString GC.textExtent: (~90% of time) org.eclipse.swt.internal.cocoa.NSLayoutManager.glyphRangeForTextContainer org.eclipse.swt.internal.cocoa.NSMutableAttributedString.setAttributedString org.eclipse.swt.graphics.GC.createString Eventually it is so slow (especially on 4k monitors where number of GC primitives is much bigger) that in some cases it makes UI unusable (while, again, it is perfectly fine on Windows or Linux). Possible solution is to rewrite the custom rendering component onto JavaFX/Swing and embed it in the RCP as Composite. Or somehow reduce the number of drawString invocations.
Has anyone picked this up? I think this is the reason why Eclipse has basically been like a slide show on macOS for years.
How is the speed of drawing on M1 Mac?
Patch for bug 574618 may improve things. It doesn't address text speed, but it enables window contents caching everywhere. Please give it a try.
Bumping this as performance is still terrible on 4.22 on macOS Monterey.
Testing on Mac M1 vs Windows machine with i5 11th gen processor I get Windows doing a GC.drawString() about 2x as fast as Mac. Faster, for sure, but not 47x. But it's hard to compare Apples with Oranges with different specs. import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class DrawStringTest { public static void main(String[] args) { var display = new Display(); var shell = new Shell(display); shell.setText("Draw String test"); shell.addPaintListener(event -> { long now = System.currentTimeMillis(); for(int i = 0; i < 200000; i++) { event.gc.drawString("0123", 0, 0, true); } System.out.println(System.currentTimeMillis() - now); }); shell.setBounds(100, 100, 200, 200); shell.open(); while(!shell.isDisposed()) { if(!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
I experience similar slowness issues using Macbook Pro i7 from 2015. Java Editor: on eclipse the problem gets worse with vertical size (horizontal space does not seem to affect). - at 20 text lines visible, the problem is barely noticeable. - at 30 text lines visible, the problem appears but only a little annoying - anything more than 60 lines and typing characters fast feels like a modem terminal from the 80s The problem does not seem to be affected by resolution. Same problem happens displaying 60 lines in a small window/small font, or large font at full screen. Output from the code posted by Phil on 2021-01-27 in multiple runs: ``` 17845 18043 18642 18658 18090 ```
I'm getting an average of 4000 ms per run on Mac Mini M1 with Monterey. On my Windows machine I get an average of 2000 ms per run.
(In reply to Phil Beauvoir from comment #11) > I'm getting an average of 4000 ms per run on Mac Mini M1 with Monterey. On > my Windows machine I get an average of 2000 ms per run. Average of 16000 ms per run on MacBook Pro (13-inch, 2017) with Monterey.
Still an issue on Eclipse 4.24
