Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java2D awt.geom.Area Performance woes  (Read 2323 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2003-04-22 17:12:20 »

Is anyone else using geom.* intensively?

It seems that the Area class is pretty horrendously crap, performance wise. For instance, new Area(...) is many times slower than typical object creation, and even Area.contains( x, y ) is EXTREMELY slow for any halfway-complex Area object.

E.g. for a CAG shape composed of 6 Circle's and about 3 subtractions and an intersection, I can see 75 ms for "new Area()" (a problem I can avoid by hierarchical caching of Area objects in a tree), and multiple milliseconds for the contains method.

Unless someone knows of an improvement to Convex Hull that can provide the "outer surface of a CAG shape" (i.e. discards any internal "holes") AND provides some not-too-hard-to-implement method of doing contains( x,y ) tests, I'm stuck with J2D's versions.

Even any tips on improving performance on them would be gratefully received.

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 57
Projects: 11


Monkey for a head


« Reply #1 - Posted 2003-04-22 18:42:01 »

Judging by the descriptions in the Area class, I wouldn't be surprised if the area is being scanline converted, so anything more complicated than simple rects or polys (ie circles, elipses, etc.) just become a series of thin rectangles Sad This is how clip regions and other irregular areas are handled, and the performance is awful there as well..

I posted a ConvexHull class in the shared code section a while ago, which would give you a starting point at least. Failing that, you could try the QuickHull algo.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2003-04-22 20:13:22 »

Quote
Judging by the descriptions in the Area class, I wouldn't be surprised if the area is being scanline converted, so anything more complicated than simple rects or polys (ie circles, elipses, etc.) just become a series of thin rectangles Sad This is how clip regions and other irregular areas are handled, and the performance is awful there as well..

I posted a ConvexHull class in the shared code section a while ago, which would give you a starting point at least. Failing that, you could try the QuickHull algo.


...but I'd expect anything based on scanline conversion to be lightning fast - you're generating bitmaps, which are just a fancy form of array, which is the fastest possible data structure for random-access. I too have noticed that rectangle-based operations in java.* libraries often blow goats, but it seems really weird that they do. I'd previously always assumed it was just poor implementations in early versions of java - have you noticed poor performance in recent (ie. >=1.3) versions?

I can do convex hull easily enough, but can't think of any simple relationship between that and the algo I need/describe. At the moment, I'm using j2d's Area.getPathIterator() to get individual path's for the different "contours" in a complex, holey Area, and compare the sizes of them to find the biggest.

P.S. - there's a bug in J2d that I haven't bothered logging yet, where composing various circles using CAG causes it to create absolutely tiny (typically 0.000001 wide/high) areas in spurious locations. Anyone testing the code visually won't see them (too small to display), but they're there!

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (349 views)
2018-11-16 13:46:03

hadezbladez (183 views)
2018-11-16 13:41:33

hadezbladez (348 views)
2018-11-16 13:35:35

hadezbladez (84 views)
2018-11-16 13:32:03

EgonOlsen (2179 views)
2018-06-10 19:43:48

EgonOlsen (2221 views)
2018-06-10 19:43:44

EgonOlsen (1378 views)
2018-06-10 19:43:20

DesertCoockie (2011 views)
2018-05-13 18:23:11

nelsongames (1668 views)
2018-04-24 18:15:36

nelsongames (2308 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!