Bug 143356 - GC.drawImage is slow on Linux for large images
Summary: GC.drawImage is slow on Linux for large images
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Felipe Heidrich CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2006-05-23 18:46 EDT by Mark Siegel CLA
Modified: 2008-06-27 11:52 EDT (History)
5 users (show)

See Also:


Attachments
test case (1.71 KB, text/plain)
2006-05-26 17:28 EDT, Felipe Heidrich CLA
no flags Details
Reproduction image (3.01 KB, application/octet-stream)
2006-08-23 13:46 EDT, Mark Siegel CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Siegel CLA 2006-05-23 18:46:15 EDT
I'm using Eclipse M6.
Version: 3.2.0
Build id: I20060331-2000

And SWT 3.2.0.v3229j.

Drawing images on Linux using GC.drawImage seems to be very slow for large image files (tested with .bmp images).

I've reproduced through the GEF Shapes example by modifying the ShapesEditPart.createFigureForModel method to draw an image in place of rectangle shapes.  Here z:\purple.bmp is a 1000x1000 pixel bitmap.

private IFigure createFigureForModel() {
	if (getModel() instanceof EllipticalShape) {
		return new Ellipse();
	} else if (getModel() instanceof RectangularShape) {
		return new RectangleFigure()
        {
              public void paintFigure (Graphics g)
              {
                  Image img = new Image (null, "z:\\purple.bmp");
                  g.drawImage (img, new Rectangle (img.getBounds ()), getBounds ());
                  img.dispose ();
              }

        };
	} else {
		// if Shapes gets extended the conditions above must be updated
		throw new IllegalArgumentException();
	}
}

On Windows, the latency of the drawImage method seems to be related to the size of the target region the image is being drawn to, however on Linux, it seems to be constant regardless of what region the image is drawn to.

This makes the drag and drop operation in the shapes editor very slow on Linux, while still fairly fast on Windows, assuming the rectangles you use are of relatively small sizes.
Comment 1 Felipe Heidrich CLA 2006-05-26 17:28:30 EDT
Created attachment 42786 [details]
test case

Hmm, I wrote a test case to reproduce this problem, not sure if it really captures the problem you are having. But the results are interesting.

On Windows, as the region increases the time to redraw also increases.
count: 200 rect: Rectangle {10, 10, 100, 100} time: 359
count: 200 rect: Rectangle {10, 10, 200, 200} time: 438
count: 200 rect: Rectangle {10, 10, 500, 500} time: 859
count: 200 rect: Rectangle {0, 0, 1000, 1000} time: 2453
Comment 2 Felipe Heidrich CLA 2006-05-26 17:32:53 EDT
I hope I doing a Billy but the number I'm getting on GTK don't make any sense:

count: 200 rect: Rectangle {10, 10, 100, 100} time: 1881
count: 200 rect: Rectangle {10, 10, 200, 200} time: 7029
count: 200 rect: Rectangle {10, 10, 500, 500} time: 228
count: 200 rect: Rectangle {0, 0, 1000, 1000} time: 1022
Comment 3 Felipe Heidrich CLA 2006-05-26 17:37:09 EDT
Carbon numbers:

count: 200 rect: Rectangle {10, 10, 100, 100} time: 53
count: 200 rect: Rectangle {10, 10, 200, 200} time: 82
count: 200 rect: Rectangle {10, 10, 500, 500} time: 428
count: 200 rect: Rectangle {0, 0, 1000, 1000} time: 2069

----

SSQ, do you know what is wrong with GTK ?

Comment 4 Steve Northover CLA 2006-08-16 12:49:03 EDT
We will investigate for 3.2.1.
Comment 5 Felipe Heidrich CLA 2006-08-21 12:37:10 EDT
Can you please retest this problem ? We had some major changes in GC (see Bug134760). I run my snippet again and I got different numbers:
count: 200 rect: Rectangle {10, 10, 100, 100} time: 106
count: 200 rect: Rectangle {10, 10, 200, 200} time: 222
count: 200 rect: Rectangle {10, 10, 500, 500} time: 1131
count: 200 rect: Rectangle {0, 0, 1000, 1000} time: 4136

Comment 6 Steve Northover CLA 2006-08-21 13:21:34 EDT
NOTE:  The changes are major so it is unlikely that we will back port them to 3.2.1.  However, it is useful to know if the situation is better in the 3.3 stream.
Comment 7 Steven Wasleski CLA 2006-08-22 16:29:50 EDT
David B, can you comment on comment 6?
Comment 8 Steve Northover CLA 2006-08-23 11:41:00 EDT
This bug report is a bit confusing.

Felipe wrote a benchmark, hoping that it captured what was happening in the GEF code.  We need to be sure of this by recreating the initial bug using GEF.  Mark please attach 'purple.bmp' and assist us if we have any problems recreating the problem in GEF (we will ask for help).  Hopefully, Felipe's code is capturing the same problem.

Meanwhile, we will investigate Felipe's code.
Comment 9 Felipe Heidrich CLA 2006-08-23 12:55:42 EDT
I can no longer reproduce the GTK numbers in comment #2 (my machine have been in a funny state).  The new GTK numbers are in comment #5.  These numbers show that when the clipping is increased, image drawing gets slower on all platforms.

NOTE:  The hardware is different between Windows, GTK and carbon so it doesn't make sense to compare the raw image drawing times (ie. Windows is not necessarily faster).

I no longer believe that my test case captures the problem.  We need a real test case from Mark (like Steve says).
Comment 10 Felipe Heidrich CLA 2006-08-23 12:56:40 EDT
We won't change code for 3.2.1 without a repeatable test case.
Comment 11 Steve Northover CLA 2006-08-23 13:02:46 EDT
I agree.  We won't fix this for 3.2.1 without a better test case.
Comment 12 Steven Wasleski CLA 2006-08-23 13:37:42 EDT
David, can your team provide a better test case?
Comment 13 Mark Siegel CLA 2006-08-23 13:46:17 EDT
Created attachment 48499 [details]
Reproduction image

Attached is the image file 'purple.bmp' I used to originally reproduce the problem.

It may take a while to set up my Linux box again, but I can try to get an SWT repro app together.
Comment 14 Felipe Heidrich CLA 2006-08-23 15:59:06 EDT
Okay, I load these plugins into my workspace:
org.eclipse.draw2d [R32_Maintenance]
org.eclipse.gef [R32_Maintenance]
org.eclipse.gef.examples.shapes [R32_Maintenance]
org.eclipse.swt [R_3_2_maintenance]
org.eclipse.swt.gtk.linux.x86 [R_3_2_maintenance]
I replaced ShapesEditPart.createFigureForModel with the code from comment 0.
Run Eclipse (self-host).
1) New->Example...->Shapes Diagram
2) In the Diagram, create a Rectangle (it draws purple).
3) Drag and resize it around.
I see no problem. What am I doing wrong ?

I also test this on Windows, same behaviour.
Note: when I resize or drag the figure it only draws a 'shade' of the figure.
Comment 15 Felipe Heidrich CLA 2006-08-23 17:35:25 EDT
My linux hardware is:
IBM IntelliStation Z Pro with 2 Intel Xeon CPU 2.66GHz, 1536Mb memory
nvidia video card.
Running FC 5, 
-sh-3.1$ rpm -q gtk2 glib2 pango atk xorg-x11-server-Xorg
gtk2-2.8.17-1.fc5.1
glib2-2.10.2-1.fc5.1
pango-1.12.1-1.fc5.1
atk-1.11.4-1.fc5.1
xorg-x11-server-Xorg-1.0.1-9.fc5
Comment 16 Steven Wasleski CLA 2006-08-29 11:55:38 EDT
David, can you or your team provide a recreatable test case?  Time is running out for 3.2.1.
Comment 17 Bogdan Gheorghe CLA 2008-06-27 11:52:01 EDT
Sorry, time ran out and without a repeatable test case we can't proceed.