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:
http://code.google.com/p/piccolo2d/issues/detail?id=63
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
http://code.google.com/p/piccolo2d/issues/detail?id=13
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
http://code.google.com/p/piccolo2d/issues/detail?id=13
PSwing doesn't work with certain swing components (tooltips,
drop-downs, scrollbars (on mouse off), etc.)
http://code.google.com/p/piccolo2d/issues/detail?id=18
JSlider fails to render knob icon under Intel Macs in Java 1.5
http://code.google.com/p/piccolo2d/issues/detail?id=63
Is the latter one fixed with your suggested change?
michael
--~--~---------~--~----~------------~-------~--~----~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
|
