OpenCPN Beta Version 3.3.1731 Released

[P_Dub]

Anybody experience the screen turning blue?
Windows 7 Ultimate
NVidia GeForce experience, with driver updated 18 june 2014
Regards

[bdbcat]

Baikal...

regarding:

in OpenGL mode works for me only to 5 on the brightness does not change. 
If you disable OpenGL okay.

This seems to be a common OpenGL driver bug. I see the trouble also on one of my Win7 systems.

Just for information, do you have any luck with OpenCPN V 3.2?

Thanks
Dave

[Baikal]

Originally Posted by bdbcat

Baikal...

regarding:

in OpenGL mode works for me only to 5 on the brightness does not change. 
If you disable OpenGL okay.

This seems to be a common OpenGL driver bug. I see the trouble also on one of my Win7 systems.

Just for information, do you have any luck with OpenCPN V 3.2?

Thanks
Dave

3.2 the same problems

[CarCode]

Originally Posted by Ptizef

Related to the display problem (#125)
I've found when it happens :
Displaying a colored overlay map in grib-pi immediately start the problem and it continues even I close grib-pi. The only way to stop the phenomenon is to restart O. I don't understand, because I did dozen and dozen times and I've never seen this before. I suppose it started with 1731
And it seems that the more I display overlays, the worth it is !
There must be some incompatibility between overlay display, 1731 display and my graphic card as I am unable to reproduce on other device
Jean Pierre

I have fixed this problem for my OpenCPN version with wxWidgets 3.1.0 and Mac OS X Mavericks with this insertion:

#if wxCHECK_VERSION(3,0,0)
        g_pi_manager->RenderAllGLCanvasOverlayPlugIns( m_pcontext, cc1->GetVP() );
#else
        g_pi_manager->RenderAllGLCanvasOverlayPlugIns( GetContext(), vp );
#endif

in function DrawFloatingOverlayObjects() of file glChartCanvas.cpp because GetContext() does not work here.

Gerhard

[seandepagnier]

Originally Posted by CarCode

I have fixed this problem for my OpenCPN version with wxWidgets 3.1.0 and Mac OS X Mavericks with this insertion:

#if wxCHECK_VERSION(3,0,0)
        g_pi_manager->RenderAllGLCanvasOverlayPlugIns( m_pcontext, cc1->GetVP() );
#else
        g_pi_manager->RenderAllGLCanvasOverlayPlugIns( GetContext(), vp );
#endif

in function DrawFloatingOverlayObjects() of file glChartCanvas.cpp because GetContext() does not work here.

Gerhard

I have not tried with 3.1.0, only 3.0.0, but I can say I get warnings that GetContext() is deprecated. Maybe someone can explain why we need to pass the context at all since nobody uses it.

[CarCode]

Originally Posted by boat_alexandra

I have not tried with 3.1.0, only 3.0.0, but I can say I get warnings that GetContext() is deprecated. Maybe someone can explain why we need to pass the context at all since nobody uses it.

So why you use deprecated functions?
Gerhard

[seandepagnier]

Maybe Dave knows the reason for passing the context to the plugins as he added this years ago. I'm fairly sure no plugin uses it for anything. This function is only deprecated since wx-3, but I think for this reason we should pass NULL for now( and in future plugin api version remove it) or find an alternative.

There are several other cases for deprecated functions being used in the non-opengl code (ie: setting a clipping region on a dc)

[CarCode]

Originally Posted by boat_alexandra

Maybe Dave knows the reason for passing the context to the plugins as he added this years ago. I'm fairly sure no plugin uses it for anything. This function is only deprecated since wx-3, but I think for this reason we should pass NULL for now( and in future plugin api version remove it) or find an alternative.

There are several other cases for deprecated functions being used in the non-opengl code (ie: setting a clipping region on a dc)

Not very nice to accuse Dave.
Dave has only not checked enough your "optimization" code.
So we got with 3.3.1731 the worst beta ever.
However with the further 28 correcting commits of Dave since 3.3.1731 it works now.
Gerhard

[bdbcat]

Folks...

Regarding OpenGL and GetContext():

There is theoretically a good reason to pass the OpenGL context to a PlugIn. Although no PlugIn does this currently, one may want to create/access its own display lists, render buffers, etc. It may even want to render on the context directly, although that might not be very good citizenship.

No extant PlugIn wants to or needs to do anything like this. So, fine.

Now, the entire concept of a referenced glContext has disappeared with wx3.0. Fortunately, this does not affect us much.

We cannot rewrite the PlugIn API to remove the reference to glContext, because that would break backwards binary ABI compatibility. That is, old PlugIns would not load if we remove or modify the argument list of the interface functions having glContext as an argument. Remember, we promise that any PlugIn that loads and runs on OCPN Version x will always at least load and run minimally on OCPN x+1. That is the only way to get PlugIn authors committed.

So, going forward, we probably just need to pass NULL for glContext to the PlugIn methods where required, and live with the vestigial overhead.

Regarding deprecated functions:
Use of deprecated functions happens all the time. When the functions actually disappear from the API, then conditional build/run must be employed. And we do that.

When we wrote the original OCPN PlugIn API, who knew that OpenGL contexts would disappear from wxWidgets sometime in the indefinite future? Its not fair to re-write history. Macroscopic time only goes in one direction, AFAIK.

Dave

[bdbcat]

Folks...

You may be wondering when/where is the next Beta. Here is a quick status report.

As you know, the bug list for 1731 is huge. We have a lot of new Flyspray issues to consider, and many, many issues only present on this Forum thread. And although 1731 is/was very frustrating, we learned lots by the exercise.

We don't get much further ahead by simply hacking on 1731 to eliminate problems in a peephole fashion. So now we are heads down focused on building a Beta that represents structurally what we need for the next production Release. And making progress.

So now it is simply a question of where (in the bug list) to stop and release a new Beta. I generally dislike releasing a Beta with known bugs, but I probably will do so this time, so that we may proceed with some more meaningful stress and platform testing.

Expect a new Beta in a week or so.

Thanks for your support

Dave

[Takao]

Hello Dave,

I use the GPS receiver of Haicom HI-408 BT for OpenCPN Ver.3.3.1731.

The GPS Receiver was not recognized on Ver.3.3.2, but on this beta version. The GPS receiver is recognized on the debug windows of OpenCPN and shows NMEA sentences. However, the mark on the up-right of the screen, which indicates GPS availability, is still red and cannot be recognized ship location.

These problem are happened on Windows 7 and Windows 8.1

Do you have any adevice for this problem ?

Takao (from Japan)

[bdbcat]

Takao...

Welcome.

Please post a screen shot of the NMEA debug window in operation. We will inspect the NMEA sentences.

Thanks
Dave

[Ptizef]

Originally Posted by boat_alexandra

pitzef,

If it's easy to reproduce, can you find the exact commit which broke it with git-bisect?

Hi
I tried to find the commit using git-bisect

I found this is between
this commit :
12/05/2014
3.3.1712
100fdbccce6865ebb356d67bad289ff5ff8f6c73
which is the last I can compile and test with OK result

And this one :

15/05/2014
Correct glCanvas setup for Windows proc addr location search.
2e0754af9bf41347cf4cb6fd6b108c8880b3011d

with is the fisrt I can compile and test NO OK


Between them, I was unable to test because either they do not compile or they crash


But the more important is I think I've found a fix for the problem with this patch :


//

@@ -1430,7 +1432,7 @@ void GRIBOverlayFactory:rawGLTexture( GLuint texture, int width, int height,
glEnable(GL_TEXTURE_RECTANGLE_ARB);
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, texture);

- glDisable( GL_MULTISAMPLE );

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);



//
After suppressing this line which seemed curious, I was unable to reproduce the display problem on both my machines


I will post a pull request for that patch


Jean Pierre

[CarCode]

Furthermore grib_pi v2.3 (latest commit 14 hours ago) is now totally broken.

Gerhard

[bdbcat]

Gerhard....

Latest GRIB is broken in what way?

Thanks
Dave