OpenCPN Beta Version 3.3.2410 Released

[bdbcat]

Gilletarom, and all other translators...

I have implemented a possibly workable solution to the problem of PlugIn translations overriding the OCPN core translations. It turned out to be straightforward to do, after gaining an an understanding of wxWidgets management of message catalog (.mo) files.

To summarize:
Translations in PlugIns that are already present in the OCPN core will be ignored. The core will take precedence on such exact duplicates.

This will be in the next Beta, so feel free to take advantage of this new policy as you see appropriate in your translations.

PlugIn authors may want to update their PlugIns in light of this change, if for example some page layout details are disturbed by using the core translations instead of the ones in the PlugIn's own .po/.mo files.


Thanks
Dave

[Hakan]

Originally Posted by bdbcat

Håkan...
Saturday, 2100 GMT.
Latest "loss of focus" correction now in github.
Let me know...

Thanks
Dave

Dave...
Success!! Now any dialogue box and its write fields are stable without loss of focus.
Many thanks for your extended Git investigation.

I'll check more on the changed font and box styles tomorrow.
G'night

Håkan

[seandepagnier]

Originally Posted by bdbcat

Translations in PlugIns that are already present in the OCPN core will be ignored. The core will take precedence on such exact duplicates.

Is it possible to report collisions in the log?

[seandepagnier]

As for the overzoom blurring. Is there a reason it is only implemented in quilted mode?

Also, in both dc and opengl it slows my computer to a crawl. Why don't we use the FBO to build it? glReadBuffer is incredibly slow.

[bdbcat]

sean....

Translation catalogs:

"Is it possible to report collisions in the log? "

Not easily. We would have to parse the .mo file. The wx methods to do this are not exposed in the API, so we would have to build them from scratch.
Not worth it, IMHO.

Dave

[bdbcat]

Sean...

re:
As for the overzoom blurring. Is there a reason it is only implemented in quilted mode?
Yes, this leaves a one-key ("q") method to toggle off the blur for a quick look at the "detail", if desired.

re:
Also, in both dc and opengl it slows my computer to a crawl. Why don't we use the FBO to build it? glReadBuffer is incredibly slow.

I wonder what code path your machine is taking here. If you have nPOT textures, we don't read pixels into the CPU space. They stay in the GPU space with glGenerateMipmap(), probably, depending on implementation.

On the bulk of Intel laptops, we don't use FBO/PBO anyway, since intel OpenGL driver implementations are so poor.

I have had to implement a glReadPixels() code path for some machines, since they don't support nPOT, and their glGenerateMipmap() is broken. Not much choice here. intel again...

Of course, dc mode will be a lot slower. We use the CPU to blur the image.

Finally, I recall your comment that showing depth soundings ("s") slows your frame rate greatly. I don't see this affect at all. Some slowing, but only measurable, not visibly detectable. So I wonder what's going on....

I have a commit nearly done which will show an estimated OpenGL frame rate on-screen, by user option. It will be interesting to compare actual numbers.

Dave

[bdbcat]

Ptizef...

On the overzoom black screen:

I could not give up. Tried another approach which might work for your system, and others like it. Should give blurring, with I hope acceptable performance. Please test and comment.

In github now.

Thanks
Dave

[seandepagnier]

Originally Posted by bdbcat

Sean...

re:
As for the overzoom blurring. Is there a reason it is only implemented in quilted mode?
Yes, this leaves a one-key ("q") method to toggle off the blur for a quick look at the "detail", if desired.

Shouldn't this be a separate toggle from quilt mode?

re:
Also, in both dc and opengl it slows my computer to a crawl. Why don't we use the FBO to build it? glReadBuffer is incredibly slow.

I wonder what code path your machine is taking here. If you have nPOT textures, we don't read pixels into the CPU space. They stay in the GPU space with glGenerateMipmap(), probably, depending on implementation.

I have npot support:

09:46:46 PHT: OpenGL-> Renderer String: Mesa DRI Intel(R) Haswell Mobile 
09:46:46 PHT: OpenGL-> Detected Intel renderer, disabling stencil buffer
09:46:46 PHT: OpenGL-> Texture rectangle format: de1
09:46:46 PHT: OpenGL-> Using Vertexbuffer Objects
09:46:46 PHT: OpenGL-> Using Framebuffer Objects
09:46:46 PHT: OpenGL-> Using FBO Stencil buffer
09:46:46 PHT: OpenGL-> Using Depth buffer clipping
09:46:46 PHT: OpenGL-> Using s3tc dxt1 compression
09:46:46 PHT: OpenGL-> Compressed tile size: 128kb (6:1)
09:46:46 PHT: OpenGL-> Minimum cartographic line width:  1.0
09:46:46 PHT: OpenGL-> Minimum symbol line width:  1.5

My driver is definitely buggy, but supports npot.

What about the case where the texture rectangle format is GL_TEXTURE_RECTANGLE_ARB? I no longer have hardware where this is the case, but I believe it exists. I don't think this format supports mipmaps.

I think glCopyTexSubImage2D is considered a slow function.

On the bulk of Intel laptops, we don't use FBO/PBO anyway, since intel OpenGL driver implementations are so poor.

You mean intel mobile drivers running windows?

I have had to implement a glReadPixels() code path for some machines, since they don't support nPOT, and their glGenerateMipmap() is broken. Not much choice here. intel again...

The part with glReadPIxels is ifdef out.

Of course, dc mode will be a lot slower. We use the CPU to blur the image.

My concern is that it is so slow that on slower machines will render the machine unresponsive for several seconds making it difficult to operate.

Is there a reason we can't just render to a smaller buffer, or just draw in the center of the screen, then stretch this to fill the screen rather than doing a costly blur/mipmap generation?

Finally, I recall your comment that showing depth soundings ("s") slows your frame rate greatly. I don't see this affect at all. Some slowing, but only measurable, not visibly detectable. So I wonder what's going on....

It occurs in areas of very dense soundings. The difference is noticable without opengl, but much more so with opengl.

I have a commit nearly done which will show an estimated OpenGL frame rate on-screen, by user option. It will be interesting to compare actual numbers.

Dave

The framerate can also be displayed by the statusbar plugin.

[bdbcat]

sean...

"You mean intel mobile drivers running windows?"

Yep, that is the worldwide center of gravity, I'm afraid.


Try my latest commits.
All this stuff works well enough on my slow Asus eeepc, 1GB, no FBO, no nPOT, no VBO. Just barely OpenGL compliant.

10:26:32 PM: Warning: unable to use NPOT texture for chart symbols
10:26:33 PM: OpenGL-> Renderer String: Intel Pineview Platform
10:26:33 PM: OpenGL-> Version reported:  1.4.0 - Build 8.14.10.2230
10:26:33 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
10:26:33 PM: OpenGL-> Texture rectangle format: 0
10:26:33 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
10:26:33 PM: OpenGL-> Vertexbuffer Objects unavailable
10:26:33 PM: OpenGL-> Framebuffer Objects unavailable
10:26:33 PM: OpenGL-> Using Depth buffer clipping
10:26:33 PM: OpenGL-> Using s3tc dxt1 compression
10:26:33 PM: OpenGL-> Compressed tile size: 128kb (6:1)
10:26:33 PM: OpenGL-> Minimum cartographic line width:  1.0
10:26:33 PM: OpenGL-> Minimum symbol line width:  1.0

General panning or [] rotation with cm93, not overzoomed, gives about 15 fps. Slow but usable.

The reported fps falls to single digits when overzoomed with all effects on. But it never stops for "seconds".

Do you have a favorite lat/lon for testing dense soundings?

Of course, we can continue to tweak performance forever. Your suggestions have merit, and there are other ideas.

But we need to stop somewhere on safe ground for a Release.

I will look at the case of the texture rectangle format is GL_TEXTURE_RECTANGLE_ARB. I think it should use the safest method, and assume that glGenerateMipmaps doesn't work in this case, even if it claims to exist.

Dave

[seandepagnier]

Originally Posted by bdbcat

The reported fps falls to single digits when overzoomed with all effects on. But it never stops for "seconds".

Try panning around without opengl, in overzoom with a rotated viewport. Your netbook is probably going to become difficult to control.

Do you have a favorite lat/lon for testing dense soundings?

How about the location of the vesta grounding:
16 38' South 59 33' East

Just zoom out (not overzoomed) to just before it switches to a lower detail map and there are many even overlapping soundings. Maybe a solution is to avoid displaying soundings that are overlapping because you can't read them anyway, and there are so many it gets very slow.

Of course, we can continue to tweak performance forever. Your suggestions have merit, and there are other ideas.

But we need to stop somewhere on safe ground for a Release.

Yes, I agree. I will continue to investigate performance for now and after a release, but for now am just looking for potentially problematic cases.

A more serious example is, in opengl mode, using raster charts, rotating the chart under overzooming is clearly broken (see attachment)

Specifically using glGenerateMipmaps in this way is slow. Normally it is used either at startup or in a background thread with shared context.

I believe a much better solution would be to shrink the viewport pixel dimensions with a fixed minimum scale, then stretch the smaller image to fill the screen. It would be much faster in both opengl and dc mode.

I will look at the case of the texture rectangle format is GL_TEXTURE_RECTANGLE_ARB. I think it should use the safest method, and assume that glGenerateMipmaps doesn't work in this case, even if it claims to exist.

Dave

It won't work because mipmaps are not supported in texture rectangles. I think this case can use the non-npot path. Some older drivers only texture rectangles, and this is where it will break.

diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index d25d4aa..f3afe22 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -2601,7 +2601,7 @@ void glChartCanvas::RenderCharts(ocpnDC &dc, OCPNRegion &region)
                     int width = wi;
                     int height = hi;
 
-                    if(g_texture_rectangle_format){             //nPOT texture supported
+                    if(g_texture_rectangle_format == GL_TEXTURE_2D) {             //nPOT texture supported
 
                         //          Capture the rendered screen image to a texture
                         glReadBuffer( GL_BACK);

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Gilletarom, and all other translators...

I have implemented a possibly workable solution to the problem of PlugIn translations overriding the OCPN core translations. ...
To summarize:
Translations in PlugIns that are already present in the OCPN core will be ignored. The core will take precedence on such exact duplicates.
This will be in the next Beta, ...
....
Dave

Grand merci. Gilletarom

[Gilletarom]

Hello Dave,

O 332410 on ASUS EEPC 1015H, W 7 stater

On a new installation, no GPS connected, no unit entered when trying to create a new connection anyway, O offers us the com port 4 and 6. It is not serious but rather abnormal.

This is something that took place with 3.2.2 and all previous beta versions. The problem seems to have already been pointed out to me by another user, but I do not know if it had been analyzed. In any case, I do not remember seeing an answer to this on any thread.

Best regards. Gilletarom

[cagney]

Originally Posted by HappySeagull

Puzzle to me
If it were just the header GD value...which has been a mystery I have often remarked upon...
Note that all these show a shifted grid on a chart that was drawn to NAD27 (and very well too!)
Note that i took the liberty of changing GD from NAD27 to NAD83 and WGS84
Note that O is happy with these.

9:07:09 AM: GPS Watchdog Timeout is: 6 sec.
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercWGS84.KAP
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercNAD27.KAP
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercNAD83.KAP
9:07:09 AM: Getting .gpx layer files from: D:\KEEPERS\Navigation\OPEN CPNinstall+help\O-3.3.14Portable\layers
9:07:09 AM: New layer 1: MARKS_LightlistDatumCheck

Attachment 94005Attachment 94006Attachment 94007
Note that the Mark taken from the list of lights does not move, chart to chart, and neither do the grids compared.
I am not saying anything except as it seems to me with my charts issued in 1996 . I have my suspicions that this is some secret held in the Temple Of O code , and I Am Not Worthy..or the charts GD just describes the drawing and not the REFs or Plys

And, from the linkhttp://opencpn.org/ocpn/chart_info where the grid is compared and said to be "funky" I note
that O does an excellent job reading whatever she really is reading,and a shifted grid is not necesarily a reflection on accuracy of position per wgs84 and gps device with the (default )wgs84 datum.

Happy

It looks like you are discussing a slightly different question.

My point only concerns charts that cannot be related to a recognized Geodetic Datum.
A typical case are NGA charts containing notes similar to this:

If O assigns a GD=WGS 84 to such charts, big errors are possible.

Example NGA 28201:



CM93 V2 is based on chart 28201 but has applied huge corrections to make it compatible with WGS84.



This is exactly the reason why we can't just assign WGS84 to a chart were GD=UNKNOWN or not stated at all.

Thomas

[Hakan]

Originally Posted by bdbcat
Håkan....
Something very strange.
If you look at the commit, you will see nothing that affects the dialog rendering code. All it does is remove a focus recapture that was in the wrong place.
Will you post a picture?

Thanks
Dave

Dave.. Report for info - no ask for action:
We're "back in business" also here.

I "hear" your words about nothing changed but for whatever reason the fonts and shape of "my" dialogue box is back to where it was at commits after 2014-12-12 until 2014-12-18. Today's pull that collected the last two days of commits normalized everything.
If you remember our discussion about the "dialogue box second row" bug in wxWidget this was solved by an extra "/n" in the create label method.
That worked although it destroyed the centring of the second row. But, a couple of core commits later the centring was suddenly there? During our sessions the last days the centring was gone again but today it's back. This is for info only and I'm not really asking why.

Well, here are two pictures for the actual correct outlook.
The first from Windows.
The second from Ubuntu where the second row is there but no centring. But I've heard that centring in Linux has newer worked and that's my experience as well.

[Hakan]

Originally Posted by bdbcat

Gilletarom, and all other translators...
.......................To summarize:
Translations in PlugIns that are already present in the OCPN core will be ignored. The core will take precedence on such exact duplicates.
..................
Dave

Dave...
Tested and it's working as of your description.

So now we have to consider if a change of a label text in BR24Radar_pi is desired. For the earlier discussed "Range" issue the new translation in BR24 is anyhow less confusing then when BR24's translation was used in OCPN.

"Over and out"
Thanks
Håkan