Cruisers Forum
 


Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
Old 15-01-2014, 16:50   #76
Registered User
 
HappySeagull's Avatar

Join Date: Dec 2010
Location: B.C.,Canada
Boat: 29'
Posts: 2,423
Re: Optimized Opencpn: Testers Needed

Hey! those [,], are cool! and I finally see that \ brings it back (not /)
..ALT works too!

OH! but don't fiddle with the mouse scroll-wheel =zoom-it's handier than a skew function IMO.
I don't "skew about" much either. North UP because routes are just dreams batting back and forth in these mountain channels.
This machine(this Dell510m) is really too slow to offer a good opinion, but I can see what Hakan is fighting with...things do get slooowwerr if I pile some rasters on with OpenGL- more so when I turn quilting off...
HappySeagull is offline   Reply With Quote
Old 15-01-2014, 22:34   #77
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by boat_alexandra View Post
...... There are actually a lot of improvements in this fork, see the git log for details. .....

http://github.com/seandepagnier/OpenCPN
Sean..or anyone.
To be able to see what more to be tested I would like to know what's added like the "[ ]" function you mentioned earlier. But I can't find the "git log" you refer to. Please advise how to find it or copy the text here.
Thanks Håkan
Hakan is offline   Reply With Quote
Old 15-01-2014, 23:18   #78
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

The "[" function
I don't think this and similar functions will work for Scandinavian folks using the "åäö" like me. See my keyboard below. To reach "[" and other characters we've to press the "Alt" key and that's not compatible with the coding. At least the way I interpret it.
(That's why the "Ctrl" key sometimes is better then the "Alt" to use as a mode-key.)
Håkan
Attached Thumbnails
Click image for larger version

Name:	clip_image001.gif
Views:	143
Size:	13.6 KB
ID:	74074  
Hakan is offline   Reply With Quote
Old 15-01-2014, 23:58   #79
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by HappySeagull View Post
....However, PageUp/PageDn is not working here...chart just zoomed outout and awaaaay........
Happy.....
Yes that's true when in OpenGL mode. I coded it in the same place as the Numeric keys "+ / -". Do you happens to have the Num keys on your keyboard so please make a test using the "+/-" keys there?
Håkan
Hakan is offline   Reply With Quote
Old 16-01-2014, 02:40   #80
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Sean...
Found the failure trig for the above Pgup/Pgdown error. But it's not solved due to to complex coding for my knowledge.
>It happens only when "Smooth zooming vector" is checked. (Happy.. please test) For some reason the smoothing never ends when the function "void ChartCanvas::OnKeyDown( wxKeyEvent &event )" in chcanv.ccp is running. I put my code there together with the "Numeric pad" events. So I assume also these "+/-" keys will cause the same error. (I don't have the num keys so I can't test it)
See my code inserted at row 1832:
Code:
   //NUMERIC PAD
    case WXK_NUMPAD_ADD:         // '+' on NUM PAD
        ZoomCanvas( 2.0 );
        break;

    case WXK_NUMPAD_SUBTRACT:    // '-' on NUM PAD
        ZoomCanvas( .5 );
        break;
 //For Scandinavian keyboards
    case WXK_PAGEUP:            // Page-up
            ZoomCanvas( 2.0 );
        break;
 
    case WXK_PAGEDOWN:          // Page-down
            ZoomCanvas( 0.5 );
        break;

    default:
        break;
Håkan
Hakan is offline   Reply With Quote
Old 16-01-2014, 05:59   #81
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Sean..
Crash when O loads the default background chart.
Scenario:
> I Created a chart group containing only some very small local charts which shall force O to load the background chart.
>While OPenGL is NOT activated the background chart was nicely loaded when I switched to the new group.
>When OpenGL IS activated and without any OpenGL options checked the crash is there as soon I switch to the new chart group.

I've a crash report available if you like. Download by this link : https://dl.dropboxusercontent.com/u/...dbbff24962.zip
Håkan
Hakan is offline   Reply With Quote
Old 16-01-2014, 12:31   #82
Registered User
 
HappySeagull's Avatar

Join Date: Dec 2010
Location: B.C.,Canada
Boat: 29'
Posts: 2,423
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by Hakan View Post
Happy.....
Yes that's true when in OpenGL mode. I coded it in the same place as the Numeric keys "+ / -". Do you happens to have the Num keys on your keyboard so please make a test using the "+/-" keys there?
Håkan
Not a problem here,Hakan. The "+,-" on this non-scandinavian keyboard work fine (opengl or not).

(I've never seen a Scandinavian Keyboard before! weirdly, I actually have an English keyboard...it has a £ key! but no Euro key-egads)
HappySeagull is offline   Reply With Quote
Old 17-01-2014, 19:02   #83
Registered User

Join Date: Aug 2009
Location: oriental
Boat: crowther trimaran 33
Posts: 4,414
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by Hakan View Post
The "[" function
I don't think this and similar functions will work for Scandinavian folks using the "åäö" like me. See my keyboard below. To reach "[" and other characters we've to press the "Alt" key and that's not compatible with the coding. At least the way I interpret it.
(That's why the "Ctrl" key sometimes is better then the "Alt" to use as a mode-key.)
Håkan
I already have a comment in chcanv.cpp related to this, but I do not posses a Scandinavian keyboard so I cannot correct it. In any case, sometimes ctrl is better, sometimes alt, sometimes meta, sometimes... so should we make this an option or switch everything to ctrl? Maybe Scandinavians can be happy in the meantime using alt to reach [ and then rotate slowly?
seandepagnier is offline   Reply With Quote
Old 17-01-2014, 19:07   #84
Registered User

Join Date: Aug 2009
Location: oriental
Boat: crowther trimaran 33
Posts: 4,414
Re: Optimized Opencpn: Testers Needed

Weather has had me pinned away from internet. I went ahead and rowed the 2km in and got completely soaked! Anyway I believe I have fixed all of the problems reported as well as a lot more, and I am ready for the next round of testing.

I updated the version to distinguish these changes, but maybe I did it wrong?


The following is probably too much detail and involved for everyone, but if you are interested and would like to provide performance feedback, read on.

I added the ability for my statusbar plugin (http://github.com/seandepagnier/statusbar_pi) to display frame rate
(display string "%02.1f") With this, anyone can measure basic performance, please post your numbers.

It is well known that the status bar (and to a lesser degree compass window) slow performance, and are incredibly inefficient for what they do. Both are disabled for my tests.

Vector and world background charts greatly benefit from the use of the fbo optimization for panning (less so for diagonal panning) in north-up mode. If the viewport is rotated, this optimization is not used so panning will be slower (although much faster than without opengl still)

All measurements are taken using keypresses, not the mouse. Diagonal panning achieved by using two arrow keys at the same time.


Results:

eee pc 900a netbook (1.6ghz atom single core) and Intel mobile 945GM (keep in mind vector charts are extra slow on intel because due to a driver bug we must use the slower depth buffer instead of the stencil buffer)


opengl:

raster charts:
25-30 fps for panning zooming and rotating single chart
15-20 fps for panning zooming and rotating quilted with 3 charts visible

vector chart in single chart mode: (see screenshot for scale used)
5-10 fps panning north-up
3-6 fps diagonal panning north-up
1-2 fps panning (rotated) or rotating
2-3 fps zooming

world background chart only (no charts visible) conveniently accessed by hiding the cm93 chart in quilt mode
zoomed out enough so china size roughly fills screen (zooming in gives faster frame rates)
5-10 fps panning (rotated) zooming rotating
30 fps panning north up


These are basically all worst case scenarios. Vector charts are often much faster at a different scale or view with less detail or items displayed. This is apparent as zooming is faster than panning, because it is traveling through scales which are faster to render during this test. I was careful to avoid needing to load data into video memory (zooming or panning very far) as this causes a "glitch" much slower frame rate while it loads data from disk and uploads to video memory.


I have a pretty good understanding of how the rendering process works, and I am fairly sure (with a lot of work) it is possible for every single test listed above to be 30 frames per second or in most cases much higher, as well as eliminate the "glitches" (when stuff has to be loaded) as it can be uploaded in a background thread in most cases just before it is needed. This applies to vector mode as well since rendering can be done in the background and the texture produced quickly extrapolated for the following 10-20 frames (while the next update is rendered in the background), same as current fbo optimization, but for all possible cases, not just panning north-up. Vector charts can also greatly benefit from display lists, or vbos.. and if stored natively to disk in this format could make loading and rendering these charts extremely fast as well as reduce disk storage space needed (once they get converted). I believe the speed of loading raster charts can be grealy improved by at least a factor of 10 by storing the compressed texture on disk and memory mapping it directly to where the graphic driver can upload. This means only 1/6th of the current amount of data need be transfered, and there are no longer any intermediate copies performed (currently 2 or 3). therefore much less ram usage (same as now if opencpn is running with no charts loaded). At the same time reducing the disk space needed to store the raster charts once converted. An additional optimization would use hardware acceleration to produce the mipmaps (currently produced in a very slow routine which consumes a significant amount of total cycles used by opencpn) and/or store these on disk as compressed mipmaps don't take a lot of space.

If the above is ever implemented, I estimate very smooth graphics and completely useable operation on very slow machines like cell phones and raspherry pi. Faster machines will be able to have smooth graphics high resolution and the cpu will still be idle. This also opens the possibilites for more taxing graphics operations in the future.. ie: projection conversions. I have no idea if/when I can actually implement these things. Any ideas/comments?

Known bugs:

The tiles used for raster chart mode are clearly visible in overzoom. This is because we do not interpolate pixel values between two different tiles (textures). I think the best way to fix this is to overlap the tiles by 1 pixel to allow for this interpolation... is it worth bothering with?

Boundaries for ENC text is calculated after it's rendered once. Unfortunately we don't know when to render it the first time so the "guess" of .25 degree box is usually badly incorrect. This results in sometimes text anomallies when panning with the fbo optimization, and text "poping" into view when zooming rather than it being part of the chart as would be expected. This is for both opengl and non.
Attached Thumbnails
Click image for larger version

Name:	opencpn_vector_framerate_test.png
Views:	172
Size:	367.8 KB
ID:	74187  
seandepagnier is offline   Reply With Quote
Old 17-01-2014, 21:06   #85
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by boat_alexandra View Post
I already have a comment in chcanv.cpp related to this, but I do not posses a Scandinavian keyboard so I cannot correct it. In any case, sometimes ctrl is better, sometimes alt, sometimes meta, sometimes... so should we make this an option or switch everything to ctrl? Maybe Scandinavians can be happy in the meantime using alt to reach [ and then rotate slowly?
Sean...
I've no problem using "Alt gr" to reach "[". It's not about that. When I type the "[" nothing happens. And I thought it's because I've to press "Alt gr" to reach "[ / ]".
When I debug I can see that the function "if( event.GetKeyCode() < 128 )" detects my "Alt gr" and when I in the next moment press the "9" key (where the "(ALt gr)-[" is) the function will only see my "9" ??
And it's the same for the key "\\". The function first see my "AL Gr" and then the "+" and it zooms.

(Sorry - I hope you understand. It's sometimes hard to express in English. )
Hakan is offline   Reply With Quote
Old 17-01-2014, 21:18   #86
Registered User

Join Date: Aug 2009
Location: oriental
Boat: crowther trimaran 33
Posts: 4,414
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by Hakan View Post
Sean...
And it's the same for the key "\\". The function first see my "AL Gr" and then the "+" and it zooms.
If you can break on line 1844 in chcanv.cpp and see which way it branches... is your keyboard azerty? If so then maybe you can provide the keycodes since I do not know what numbers to use.
seandepagnier is offline   Reply With Quote
Old 17-01-2014, 21:51   #87
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 4,119
Re: Optimized Opencpn: Testers Needed

Quote:
If you can break on line 1844 in chcanv.cpp and see which way it branches... is your keyboard azerty? If so then maybe you can provide the keycodes since I do not know what numbers to use.
>No -sorry -the "Alt gr" key is maybe not listed? The wxKeyEvent says:
wxKeyEvent {m_x=??? m_y=??? m_keyCode=??? ...} wxKeyEvent

And the key_char is grey during the first brake and on the next turn its sees the 9. key_char 57 '9' char

> No it's a qwerty keyboard. See post #78 for a picture.

> To be more confused please see http://en.wikipedia.org/wiki/AltGr_key
Hakan is offline   Reply With Quote
Old 18-01-2014, 00:19   #88
Registered User
 
jonasaberg's Avatar

Join Date: Jul 2008
Location: Kristiansand, Norway
Boat: Wasa 410
Posts: 309
Re: Optimized Opencpn: Testers Needed

Quote:
Originally Posted by boat_alexandra View Post
I have a pretty good understanding of how the rendering process works, and I am fairly sure (with a lot of work) it is possible for every single test listed above to be 30 frames per second or in most cases much higher ..., [Long list of possible optimization] ... If the above is ever implemented, I estimate very smooth graphics and completely useable operation on very slow machines like cell phones and raspherry pi.
I think this sound fabulous and opens for use of really low spec - low power navigation equipment. It would be a fantastic improvement for us sailors who battle with keeping the power consumption down to reduce the time needed for recharging batteries during longer voyages.

I really, really hope this work will be done.
jonasaberg is offline   Reply With Quote
Old 18-01-2014, 01:17   #89
Registered User
 
Viking Sailor's Avatar

Join Date: Nov 2006
Location: San Francisco Bay
Boat: Fantasia 35
Posts: 1,251
Re: Optimized Opencpn: Testers Needed

Sean,

How about a key assignment page that allows a selected key to be assigned to an item in a list of shortcuts. Similar to a color/font selection operation.

I am thinking of a process something like:

Open the shortcut key assignment page.

1) Select "Learn", "Remove", or "Done"

2) Selected "Learn", press key (on keyboard) to be assigned, display key code and current assigned shortcut (if any).

3) Display list of shortcuts (*), select shortcut to be assigned/reassigned.

4) Select "Assign" to assign key to shortcut, or select "Cancel" to cancel assignment.

5) Update current assignments, return to step 1.

6)Selected "Remove", display list of shortcuts (*), select shortcut to be removed/unassigned, display assigned key code.

7) Select "Remove" to unassign key code from shortcut, or select "Cancel" to cancel operation.

8) Update current assignments, return to step 1.

9) Selected "Done", Save current assignments, exit shortcut key assignment page.

(*) It would be nice if the list showed which shortcuts were already assigned and which were not yet assigned. Maybe font or color.

To handle different language possibilities, the translators could also provide key assignments for their common keyboards. The assignment page could also provide a selection list for included keyboard assignments that would override the one installed based upon the selected local language.

Sorry if this sounds like a lot of work, it is just an idea.

Best regards,

Paul
Viking Sailor is offline   Reply With Quote
Old 18-01-2014, 02:19   #90
Registered User
 
Gilletarom's Avatar

Join Date: Mar 2010
Location: France
Boat: 10.50 mètres
Posts: 2,964
Re: Optimized Opencpn: Testers Needed

Hello,
Quote:
Originally Posted by boat_alexandra View Post
.....Anyway I believe I have fixed all of the problems reported as well as a lot more, and I am ready for the next round of testing.
I updated the version to distinguish these changes, but maybe I did it wrong?

...... This is for both opengl and non.
I read your #84 post.
I confess I do not quite understand from reading your post # 84. It is too technical

I saw that you wanted to implement a plugin called statusbar . I found the jar file of this plugin and I made a French version of the current language file. It seems to me that this translation has helped me a bit to figure out where you were going with this plugin.
Here attached the language file in French , even if it is useless for now.

Moreover , I note that this work, you have committed , is not followed by many a sailor. The reason is that those below can not test your suggestions.

Now this work will modify deeply the structure and operation of the main part of OpenCPN software .

Personally, I do not know compiled (I'm on Windows 7). So I can only wait a sailor as Hakan has the good idea to put in a new version ....

Should happen to propose compiled versions accessible and easy to install using the installer OpenCPN . Only then will your work (can be ) tested and we can be confident (and Dave too).
Attached Files
File Type: doc French_language_file_opencpn-statusbar_pi_V0.1.zip.doc (4.5 KB, 57 views)
Gilletarom is offline   Reply With Quote
Reply

Tags
opencpn, enc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Advertise Here


All times are GMT -7. The time now is 15:59.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.