Optimized Opencpn: Testers Needed

[seandepagnier]

Originally Posted by ChuckSK

Sean

Here is a patch that fixes crashes when the vp is rotated.

diff --git a/src/bitmaps/styles.xml b/src/bitmaps/styles.xml
index df2cd28..25e9a19 100644
--- a/src/bitmaps/styles.xml
+++ b/src/bitmaps/styles.xml
@@ -219,6 +219,7 @@
 			</icon>
 			<icon name="CompassRoseBlue">
 				<icon-location x="620" y="60"/>
+				<size x="32" y="32"/>
 			</icon>
 			<icon name="polyprj">
 				<icon-location x="740" y="20"/>
@@ -702,6 +703,7 @@
 			</icon>
 			<icon name="CompassRoseBlue">
 				<icon-location x="620" y="60"/>
+				<size x="32" y="32"/>
 			</icon>
 			<icon name="polyprj">
 				<icon-location x="280" y="160"/>
@@ -1178,6 +1180,7 @@
 			</icon>
 			<icon name="CompassRoseBlue">
 				<icon-location x="620" y="60"/>
+				<size x="32" y="32"/>
 			</icon>
 			<icon name="polyprj">
 				<icon-location x="280" y="160"/>

Thanks for the patch, buy why? How does it crash?

[ChuckSK]

In compasswin.cpp line 209. The wxRect passed to GetSubBitmap is invalid. The default size of the icon was 32x40 which violated the available size when it was rotated. It appears that the last toolbar icon size is used as a default size.

Notice that the compass image moves around while it rotates.

I hope that makes sense.

[rooiedirk]

On my Gentoo box the chartcanvas turn grey when panning and chart quilting is on and
OpenGL enabled.
Toolbox, chartbar and grid remain visable
Both CM93 and raster charts.
chart quilting off and or OpenGL disabled. works nice.

Smooth panning on or off doesn't make a difference.
O code updated one hour ago.
Dirk

[seandepagnier]

Originally Posted by ChuckSK

In compasswin.cpp line 209. The wxRect passed to GetSubBitmap is invalid. The default size of the icon was 32x40 which violated the available size when it was rotated. It appears that the last toolbar icon size is used as a default size.

Notice that the compass image moves around while it rotates.

I hope that makes sense.

It really doesn't make sense. I checked in the debugger, the size of the icon is 32x32 for all 3 styles. If an icon size is not specified in the xml, it is set to zero (default for wxSize) and then on styles.cpp:185 when it is queried (right before rotated), you can see it sets the size to toolSize which the default size of 32x32 which is specified in styles.xml on line 14.

I'm trying to get to the root of the problem, but I don't understand why you have found what you did. Also, this would apply to course up mode (in master branch as well) which uses a different icon but also does not specify size, and no one has ever reported crashes there.

Originally Posted by rooiedirk

On my Gentoo box the chartcanvas turn grey when panning and chart quilting is on and
OpenGL enabled.
Toolbox, chartbar and grid remain visable
Both CM93 and raster charts.
chart quilting off and or OpenGL disabled. works nice.

Smooth panning on or off doesn't make a difference.
O code updated one hour ago.
Dirk

I don't understand why you get a gray screen.

I would like you to try commenting out line glChartCanvas.cpp:2662 "glClear( GL_COLOR_BUFFER_BIT );" and recompile.
Also, please post the part of opencpn.log with all the OpenGL-> parts.
When you have the gray screen, do you see ships, waypoints, routes, emboss (depth overzoom) anything at all or only gray? If you remove all charts, do you get the background map or only gray?

Thank you for testing.

[seandepagnier]

Future of optimizations and ideas.

I'm beginning to realize that optimizations are really endless. I have so many ideas. Using quad trees for bounding boxes would greatly speed up vector rendering as would storing the lat/lon coordinates in graphics card memory and performing the projection calculation on the gpu. For raster charts, I could use pixel buffers, and multiple threads, so that while the texture is being created, the cpu doesn't block in an idle loop as it currently does, and could also take advantage of multiple cores. Then for both raster and vector cases, could implement a sophisticated priority heap to prepare tiles _before_ they are needed, so for example, zooming in on cm93 you wouldn't notice any delay going from one scale to the next because it would start loading in a background thread when it realizes it will need it in 100 frames not _this_ frame. The world background chart could have similar optimizations. This could even alleviate the need for the compressed cache on faster machines.

I noticed that with the US ENC vector charts, everytime you view a chart for the first time, it must do many calculations. This is very annoying. I propose an option to precompute all of them (maybe it takes a few hours, but is done when you are sleeping) or possibly to just start computing it while you are using it, and uses opengl to offload the rendering bits (it generates thumbnails) to the gpu, as well as using multiple threads for multi-core machines.

The startup time is only 50 milliseconds on my chromebook, but on slow computers it takes a few seconds. I greatly improved this by not loading the plugins that are not enabled, but things like parsing all the xml, loading things for vector charts even if you are not using them, etc can be done in a lazy way so that opencpn starts and is usable much sooner.

These are a few basic ideas, but I think already more work than what I have already done. Maybe I should ignore all of this, and work toward merging instead.

I really want to get on to the next step which is to support more than mercator. Mercator is not useful in high latitudes, and also misleading for visualizing routes and understanding weather patterns (grib climatology) etc, the list goes on.. mercator is made for flat paper, and was invented a long time ago. We have computers that can do much more now.

I would like to see support for standard mercator, transverse mercator (user defined pole), polyconic (user defined pole and theta), polar (with user defined pole), and then spherical and ellipsoidal models which render using actual 3d geometry as well as possibly others. All of these except standard mercator for raster charts would require opengl, and certain extensions, because the graphics card has to convert the projection on the fly in realtime (much like the way the weatherfax plugin can convert polar charts to mercator) Most graphics cards made in the last 10 years can do this efficiently. It is possible to support these projections for vector charts without opengl as well.

[ChuckSK]

Originally Posted by boat_alexandra

It really doesn't make sense. I checked in the debugger, the size of the icon is 32x32 for all 3 styles. If an icon size is not specified in the xml, it is set to zero (default for wxSize) and then on styles.cpp:185 when it is queried (right before rotated), you can see it sets the size to toolSize which the default size of 32x32 which is specified in styles.xml on line 14.

I'm trying to get to the root of the problem, but I don't understand why you have found what you did. Also, this would apply to course up mode (in master branch as well) which uses a different icon but also does not specify size, and no one has ever reported crashes there.

Thank you for testing.

Look at style.xml line 484 and line 974 where the toolsize for Journeyman styles are set to 38x32. These are the values I see in the debugger.

The crashes only occur with Journeyman styles.

In course-up mode the master branch crashes too.

In release mode the problem displays as a disappearing icon, in debug mode it causes a debug alert and then a crash.

It appears that the problem has been around for a while. If the compass icon moves around in its box during rotation the icon size is incorrect.


Chuck

[rooiedirk]

Originally Posted by boat_alexandra

I don't understand why you get a gray screen.

I would like you to try commenting out line glChartCanvas.cpp:2662 "glClear( GL_COLOR_BUFFER_BIT );" and recompile.
Also, please post the part of opencpn.log with all the OpenGL-> parts.

YES: commenting out 2664 does the trick. No more grey screens ;-).
Attached to log files (I did add some comment at the top of the logfiles)
Dirk

[seandepagnier]

Originally Posted by ChuckSK

Look at style.xml line 484 and line 974 where the toolsize for Journeyman styles are set to 38x32. These are the values I see in the debugger.

The crashes only occur with Journeyman styles.

In course-up mode the master branch crashes too.

In release mode the problem displays as a disappearing icon, in debug mode it causes a debug alert and then a crash.

It appears that the problem has been around for a while. If the compass icon moves around in its box during rotation the icon size is incorrect.


Chuck

This appears then a long standing bug and is not specific to optimium. It is just now that it is much easier to rotate the viewport, it was found. I have fixed numerous bugs related to rotated viewports already. I don't think many users used this feature, even less with journeyman, and even fewer with your specific setup. I will add size to styles.xml so hopefully you don't have any more problems now.

Originally Posted by rooiedirk

YES: commenting out 2664 does the trick. No more grey screens ;-).
Attached to log files (I did add some comment at the top of the logfiles)
Dirk

That is rather annoying. You will notice on quilted mode, with cm93 charts, if you zoom out as far as possible and look around the entire workd, you get corrupted drawing over central asia. The clear was to ensure this area would remain grey, and works fine for me...

Maybe you can change

bool bad_stencil_code = false;

from false to true in glChartCanvas.cpp and let me know if this has any effect.

Also.. when the screen is gray, can you still see ships or waypoints or anything?

This may be a bug in the gallium driver.

[rooiedirk]

Originally Posted by boat_alexandra

Maybe you can change

bool bad_stencil_code = false;

from false to true in glChartCanvas.cpp and let me know if this has any effect.

Also.. when the screen is gray, can you still see ships or waypoints or anything?

Changing bad_sten... no difference.
On a grey screen I do see: Own ship, AIS, track, grid
I don't see: Waypoints and route

Originally Posted by boat_alexandra

This may be a bug in the gallium driver.

When I change the openGL driver from Galium to standard, the problem also disapears.
Looks indeed something with the galium driver:

localhost dirk # eselect mesa list    
i915 (Intel 915, 945)
  [1]   classic *
  [2]   gallium
i965 (Intel GMA 965, G/Q3x, G/Q4x, HD)
  [1]   classic *
r300 (Radeon R300-R500)
r600 (Radeon R600-R700, Evergreen, Northern Islands)
sw (Software renderer)
  [1]   classic *
  [2]   gallium
localhost dirk #

Cental Asia looks fine for me, even with commented out glClear( GL_COLOR_BUFFER_BIT );
Dirk

[seandepagnier]

Originally Posted by rooiedirk

Changing bad_sten... no difference.
On a grey screen I do see: Own ship, AIS, track, grid
I don't see: Waypoints and route



When I change the openGL driver from Galium to standard, the problem also disapears.
Looks indeed something with the galium driver:

localhost dirk # eselect mesa list    
i915 (Intel 915, 945)
  [1]   classic *
  [2]   gallium
i965 (Intel GMA 965, G/Q3x, G/Q4x, HD)
  [1]   classic *
r300 (Radeon R300-R500)
r600 (Radeon R600-R700, Evergreen, Northern Islands)
sw (Software renderer)
  [1]   classic *
  [2]   gallium
localhost dirk #

Cental Asia looks fine for me, even with commented out glClear( GL_COLOR_BUFFER_BIT );
Dirk

In that case, I should keep note that glClear cannot work with framebuffer object for some gallium drivers because they have a bug in the driver. (if you set m_b_DisableFBO = true instead of false on line glChartCanvas.cpp:999 I think it will work as intended)

We could implement a work-around and detect the gallium driver and disable the clear in software but...

In opencpn master branch, in non-opengl mode, when quilting is turned on, central asia goes grey. With opengl on, central asia also renders correctly initially, but when panning it becomes corrupted. This is actually a bug I was trying to fix. The easy way was to do a clear (which is done in non-gl mode) which also could affect rendering in very very rare cases elsewhere, but this isn't an actual fix to the real problem which is somewhere the quilting code (which I tried very hard not to touch) is not computing the rendered region correctly. For this reason, I think I will just remove the clear since it is a temporary fix (See comment) and eventually we can fix the real problem.

Thank you for testing

[cagney]

Sean
You wrote

I'm beginning to realize that optimizations are really endless.

True..
but I think that your present code looks OK to merge with the main tree.
It's really a leap forward in performance, and will mean a much better stable release.
Anything more to wrap up before you do a pull request?
I hope that you keep on working on all your optimizations in the betas after the next stable release. Your optimizations, the support for S63 charts and the much improved grib plugin will contribute to a very good stable release.

Thomas

[Hakan]

Sean..
A report from a test of a Git pull from today.
It's now on the way to be really good. The crashes I earlier reported when mixing raster and vector charts are not there. Now I can also zoom in and out in raster charts without problem. Two issues to report though:
-Stepped zoom using vector, CM93, charts. In one zoom level a detailed part is black but returns to normal when zooming further. See the three captures.
-With texture compression on and using raster charts the colour is in some scales wrong?? See picture 4. The centre part is as it should be. If texture compression is not checked everything is normal.

Håkan

[bcn]

Originally Posted by cagney

I hope that you keep on working on all your optimizations in the betas after the next stable release. Your optimizations, the support for S63 charts and the much improved grib plugin will contribute to a very good stable release.

Thomas

Here a question for Sean and Dave:
will S-63 charts share this improvements as those are in a different SENC?

Hubert

[rooiedirk]

Extended Light Sectors are showing some strange effects using opengl. (see pict)
With openGL off they are normal.
Is this also a i915 driver effect??
Using today's code. (19-4 17:00UTC)
Dirk

[seandepagnier]

If only I could apply optimizations to my boat's sailing performance... (48 hours and 48 miles, and I sit right now 3 miles from a town going nowhere due to lack of wind)

Originally Posted by cagney

Sean
You wrote

True..
but I think that your present code looks OK to merge with the main tree.
It's really a leap forward in performance, and will mean a much better stable release.
Anything more to wrap up before you do a pull request?
I hope that you keep on working on all your optimizations in the betas after the next stable release. Your optimizations, the support for S63 charts and the much improved grib plugin will contribute to a very good stable release.

Thomas

It still isn't really "ok" but I'm beginning to find more and more bugs in the master branch as well which I am fixing. I think I still need more testing. Then I have to break this monster change into reasonable small changes (makes finding regressions if any much easier)

Originally Posted by Hakan

Sean..
A report from a test of a Git pull from today.
It's now on the way to be really good. The crashes I earlier reported when mixing raster and vector charts are not there. Now I can also zoom in and out in raster charts without problem. Two issues to report though:
-Stepped zoom using vector, CM93, charts. In one zoom level a detailed part is black but returns to normal when zooming further. See the three captures.
-With texture compression on and using raster charts the colour is in some scales wrong?? See picture 4. The centre part is as it should be. If texture compression is not checked everything is normal.

Håkan

Hakan,

The color issue is windows specific. I think maybe you generated a cached image before I made a fix. Is this with compression caching also enabled? If so, delete the files in the raster_texture_cache directory from (wherever opencpn.log is)

For the black screen.. does the problem go away without opengl? Do you by any chance have this problem in the master branch as well or only this one? What exact latitude and longitude are you at when you find this?

Originally Posted by bcn

Here a question for Sean and Dave:
will S-63 charts share this improvements as those are in a different SENC?

Hubert

I don't know if right away everything will work, but with little effort, yes.

Originally Posted by rooiedirk

Extended Light Sectors are showing some strange effects using opengl. (see pict)
With openGL off they are normal.
Is this also a i915 driver effect??
Using today's code. (19-4 17:00UTC)
Dirk

I have also i915 driver and I get so many strange effects. In any case.. what latitude/longitude? I am still trying to work many of these out.