I also did a performance comparison of the time spent in PSwing.paint for the startup sequence for TestPSwing.  There are 25 calls to PSwing.paint(PPaintContext) on startup, and the buffered version takes a total of 0.154 seconds while the unbuffered version takes 0.144 seconds.  I think the motivation for buffering in PSwing was to make it so the PSwing could just blit if nothing had changed (and render into the buffer when there is a change), but it looks like it's not being done this way (and it would take a great deal of work to get this working properly anyways).  Are there any functional or nonfunctional reasons we should leave the current PSwing implementation of buffering enabled?  I'm not sure of all the impacts this might have on client code.

Sam Reid

Samuel Robert Reid wrote:
For the knob icon/Mac issue, you can use the test included in the link:
For the file: TestPSwingJSlider.java.  We have verified that disabling PSwing.paint's buffering resolves the problem for this issue.

The other 2 issues you identified don't seem impacted by this fix.  Also regarding
PSwing components cause extraneous redraws

I enabled PDebug.debugRegionManagement and the behavior for TestPSwingJSlider looked correct, even for slider knob areas.  So I think that ticket needs a self-contained reproducible code snippet to demonstrate the problem before more work should be done on that.

I also noticed that the buffering is causing components to look fuzzy; I created issue 83 to track this, and included screenshots (and a version of PSwing.java that skips buffering).

Let me know what you think,
Sam Reid

Michael Heuer wrote:
Samuel Robert Reid wrote:

My group and I have found that the buffering in PSwing.paint can cause
rendering problems, such as the slider knob doesn't render on OS X 10.5
(if there are ticks or labels on the slider).  Also, I don't see the
advantage of buffering in PSwing.paint, since the intermediate buffer is
directly rendered to the screen anyways.  It seems like drawing directly
to the Graphics2D in the PPaintContext would be faster, rather than
drawing to a new buffered image then drawing that to the Graphics2D.
Any reasons we shouldn't remove this layer of buffering?

Is there a particular example or test case that we could use to
compare the two implementations on different platforms?

There are several related issues:

PSwing components cause extraneous redraws

PSwing doesn't work with certain swing components (tooltips,
drop-downs, scrollbars (on mouse off), etc.)

JSlider fails to render knob icon under Intel Macs in Java 1.5

Is the latter one fixed with your suggested change?



Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en

Reply via email to