Sign Up, Lost Password
Comments for Fast graphics
Return to Fast graphics
I would highly recommend getting rid of the try-catch blocks around the writing, and instead check the bounds yourself. This would increase the speed a lot, and possibly allow the routines to handle boundaries a little more intelligently. Have you run any tests to see how these routines compare to the built in Java ones?
1. Thanks for the tip, 2. No, not yet. I'll do it after removing the try-catch blocks
A new version of this scenario was uploaded on Thu Aug 02 11:58:45 UTC 2012 -Optimized performance -Added advanched testing: in GraphicsWorld, change the 'advanchedTesting' bool to 'true', and you'll get more precise results. I'll add triangle drawing and filling this week, and I'll also compare it to Java's standard classes, so stay tuned!
A new version of this scenario was uploaded on Thu Aug 02 15:30:39 UTC 2012 -Added triangle drawing -Added triangle drawing and filling
A new version of this scenario was uploaded on Thu Aug 02 17:41:19 UTC 2012 Better documentation
@Builderboy2005 Line drawing time for Graphics object: 0,002 mills Mine: 0,03 millis or 0,02 mills. Both a line from loc (600,0) to (0,400). So mine is slower :(
U can use getAwtImage() to get a BufferedImage of a GreenfootImage creat a Graphics2D on that BufferedImage, and then do your painting on the Graphics2D could be better(I guess :) some set jobs on Graphics 2D could bring the paint jobs to GPU I would chet that out Later
After testing (my above comment), I discovered already that Graphics uses the GPU. And about using the awt Image of a GreenfootImage, 2 things: -I created this scenario to show people some algoritms, being the fastest would be fun, but wasn't my first goal. -I've looked at the code of GreenfootImage, and they use a Graphics2D instance to draw.
try sun.java2D.opengl = true; to let openGL work and on windows, Graphics2D world work in DirectX way first try sun.java2d.d3d = true; to get faster maybe
O, didn't know openGL was integrated with java, thanks!
It did't work on every OS, but most of them
A note on the performance side of things - if you're trying to go faster than the built in library classes, I can near guarantee that however much work you put in you won't manage it! There's many reasons for this, from the sheer amount of manpower put in, to the close links the guys writing the library code have with the ones implementing the VM, to (as mentioned) the fact that on all common platforms the AWT graphics class will use some form of hardware acceleration. That's not to say this scenario is worthless at all - demonstrating algorithms and how they work is a nice idea for a scenario in all manner of cases. Just don't get too hung up on trying to drive to be the fastest :-)
@mjrb4 I already said that being the fastest wasn't my first goal, but it would be fun if it turned out te be (which will be impossible for me, because as you said, the AWT graphics use hardware). But anyway, thanks for the comment!
A new version of this scenario was uploaded on Thu Aug 23 10:53:55 UTC 2012 -Bug fix in advanched testing -Scenario is now unlocked
A new version of this scenario was uploaded on Thu Aug 23 11:05:32 UTC 2012 Another bug fix in advanched testing