Slow repaint of PSwing components when zooming (from 1.2 to 1.3)

[GoogleCodeExporter]

Moving from 1.2 to 1.3 has caused zooming of PSwing components to crawl on
my Mac. It seems this release includes several PSwing repainting related
changes, but I cannot make sense of which changes may have caused this
behavior.

What steps will reproduce the problem?
1. Run PSwingExample2
2. Use mouse to zoom in or out

What is the expected output? What do you see instead?
With Piccolo 1.2, the view updates smoothly. Now, with Piccolo 1.3, the
view zooms updates very slowly.

What version of the product are you using? On what operating system?
Piccolo 1.3, Mac OS X (10.5.8)

Please provide any additional information below.

Original issue reported on code.google.com by mikke...@gmail.com on 31 Mar 2010 at 8:37

[GoogleCodeExporter]

I believe there were also some PSwing changes in 1.2 to 1.2.1, have you tried
comparing with that version?

I have noticed that PSwing in 1.3 is slow on Mac OSX PowerPC with jdk 1.5, I 
just
don't remember it being fast in earlier versions.  I will confirm.

Original comment by heue...@gmail.com on 9 Apr 2010 at 9:37

[GoogleCodeExporter]

Good call, I hadn't checked with the 1.2.1 release. However, I just did and for 
me
that works like the 1.2 release, that is, much smoother updating that with 1.3.

I use an Intel-based Mac with jdk 1.5.

Original comment by mikke...@gmail.com on 10 Apr 2010 at 8:32

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 27 Aug 2010 at 4:17

• Added labels: Toolkit-Piccolo2D.Java

[GoogleCodeExporter]

Possibly related to Issue 154.

Original comment by heue...@gmail.com on 22 Dec 2010 at 2:01

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Medium, OpSys-OSX, Effort-Medium, Component-Extras, Milestone-1.3.1

[GoogleCodeExporter]

Before Issue 82, PSwing would render to a buffer and then render that buffer to 
the Graphics2D. The result would be that the buffer would undergo the applied 
transforms.

Issue 82 changed this so that the Swing component rendered directly to the 
(transformed) Graphics2D. It turns out the painting a JComponent with transform 
applied is much more expensive than painting the buffer.

Of course you lose fidelity when translating the buffered version (see picture.)

Should we restore the buffered approach? Should we make this configurable?

Original comment by atdi...@gmail.com on 5 Mar 2011 at 9:36

Attachments:

• 2v3.jpg

[GoogleCodeExporter]

When I say "much more expensive", I've only tested this behavior on Mac, so I'm 
not sure if other platforms suffer the same severe degradation.

Original comment by atdi...@gmail.com on 5 Mar 2011 at 9:42

[GoogleCodeExporter]

So testing on Windows Vista, the paint performance is much better.

Original comment by atdi...@gmail.com on 5 Mar 2011 at 10:27

[GoogleCodeExporter]

Are you sure it was Issue 82?  r458 doesn't appear to change the way PSwing 
renders.

Also, what are you using to compare performance?  I don't use PSwing myself, so 
I usually just check that the PSwing examples look reasonable.  If you have a 
test class or benchmark, please attach it here.  I can run it on 32 & 64 bit 
OpenJDK on linux and Mac OSX to compare.

Original comment by heue...@gmail.com on 6 Mar 2011 at 3:35

[GoogleCodeExporter]

Sorry - it was Issue 83, r467.

I'm using PSwingExample and notice a clear degradation from release-1.2 when 
zooming. 

For more concrete performance numbers, I hacked PSwing.paint() with the old 
buffering behavior.

On my machine, with the buffering, I see paint() consistently take < 1 millis. 
Without the buffering I see > 150ms consistently.

I've attached a patch to PSwing that can be applied to release-1.3 so you can 
see the behavior. The patch is NOT intended as a fix or for promotion. It 
constructs a buffer every time and doesn't do any of the optimizations that 
v1.2 did.

Original comment by atdi...@gmail.com on 6 Mar 2011 at 8:08

Attachments:

• PSwing-buffer-demo.patch

[GoogleCodeExporter]

Unless there come any comments to contrary, I'm going to look into making the 
buffering of Swing components configurable, with the default being no buffering.

I'm going to target fixing this for the 1.3.1 release, unless there is higher 
interest in getting the release out asap.

Original comment by atdi...@gmail.com on 27 Mar 2011 at 9:45

[GoogleCodeExporter]

Committed revision 1122.

Original comment by atdi...@gmail.com on 29 Mar 2011 at 4:12

[GoogleCodeExporter]

Committed revision 1123. (trunk commit)

Original comment by atdi...@gmail.com on 29 Mar 2011 at 4:25

[GoogleCodeExporter]

Ok, fix is in for both branch and trunk. Please verify.

Original comment by atdi...@gmail.com on 29 Mar 2011 at 4:27

• Changed state: Fixed

[GoogleCodeExporter]

Committed revision 1124 (branch). 

Original comment by atdi...@gmail.com on 29 Mar 2011 at 5:02

[GoogleCodeExporter]

Committed revision 1125 (trunk).

Original comment by atdi...@gmail.com on 29 Mar 2011 at 5:05

[GoogleCodeExporter]

Original comment by atdi...@gmail.com on 30 Mar 2011 at 12:22

[GoogleCodeExporter]

Original comment by atdi...@gmail.com on 2 Apr 2011 at 2:37

• Changed state: Verified