Closed GoogleCodeExporter closed 9 years ago
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
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
Original comment by heue...@gmail.com
on 27 Aug 2010 at 4:17
Possibly related to Issue 154.
Original comment by heue...@gmail.com
on 22 Dec 2010 at 2:01
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:
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
So testing on Windows Vista, the paint performance is much better.
Original comment by atdi...@gmail.com
on 5 Mar 2011 at 10:27
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
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:
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
Committed revision 1122.
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 4:12
Committed revision 1123. (trunk commit)
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 4:25
Ok, fix is in for both branch and trunk. Please verify.
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 4:27
Committed revision 1124 (branch).
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 5:02
Committed revision 1125 (trunk).
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 5:05
Original comment by atdi...@gmail.com
on 30 Mar 2011 at 12:22
Original comment by atdi...@gmail.com
on 2 Apr 2011 at 2:37
Original issue reported on code.google.com by
mikke...@gmail.com
on 31 Mar 2010 at 8:37