What does Failed to resize VBO

[PaulAustin]

I am using the Java Runtime 10.1.1 on Windows (Vista) with Java 1.6.0_37.

I have a polygon layer that includes about 1,000 polygons covering the Province of British Columbia in Canada. When added to the map I get the following exception.

Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Failed to resize VBO
at com.esri.map.JMap.nativeDrawMapDirectToBuffer(Native Method)
at com.esri.map.JMap.paintComponent(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at com.esri.map.JMap.paint(Unknown Source)

I have tried the data in a map package connected to SDE, a map package with embedded data and also manually adding the graphics to the layers and they all cause the error.

Any ideas?

[PaulAustin]

Looks like it was caused by an out of memory error.

Any chance there could be more meaningful exceptions thrown by the native code?

[MarkBaird]

I take the point about the error message, and I'll see where this comes from.

However I not having much luck in reproducing the issue.  I have a test which creates a graphics layer to which I add 5000 polygons each with 10,000 verticies. It takes a while to render and isn't the most responsive map I've ever seen but it's not thowing the error you are experiencing.

It's maybe that you have a lower spec machine, but either way I would encourage you to look at your data and see if it is suitable for the scales you are using it at.

Consider the resolution at which your data was digitised.  If you have a coast line which was digitised every 1metre, when you zoom out to a country scale, you will be putting a big load on your database.  Consider generalizing your data for certain view scales.  This is a very common cause for any GIS or mapping application performing badly or maybe running out of memory in your case.

[PaulAustin]

It wasn't that data that caused the out of memory. It was another thread that was creating other objects that caused the out of memory. I'm working on reducing the memory footprint of that other process.

I started creating another test application that replicated the data to be displayed so I could narrow down the issue. That test frame didn't have the issue. The only difference was that other thread. So I removed that and the problem went away which is why I figured it was a memory related issue.

Until yesterday when we upgraded to 10.1.1 the whole application crashed on a C++ new call. 10.1.1 through the RuntimeException.

Yes we will be using scale dependent rendering for the layers which have large volumes of data.