The Electronic Charting "Zoom Problem"

[champ8242]

Originally Posted by hellosailor

In hindsight it is so obvious.(G) And if the user happens to have a 36" display at hand and wants to use that as the "overwatch" screen, so be it. Computers with four to eight cores, hell, even cell phones with four to eight cores, are common these days. Multiple displays, natively supported. So what's missing?
......

Meanwhile I'll expect the new beta to be ready and on my desk, let's say, no later than 8AM Monday morning. Plenty of time for some trivial program changes.(VBG)

Why wait till Monday! solve it today! Why push others (SW developers) if you can do it yourself? Apparently you have your second (or third or..) screen already. Just spend like $35 on a second (or third or ...) PI run an instance of OpenCPN on each et voila. Your problem solved.

Bart

[Dockhead]

Originally Posted by hellosailor

Very few "electronic map" companies have key people with extensive cartographic experience, graphic design experience, and programming experience. I raise this because there are some things that are obvious (like showing a circle of position to indicate uncertainty, rather than a pinprick all the time) that conventional cartographers and graphic artists would know. And yet big e-mapping companies (including Gargoyle Maps) managed not to implement until they'd been hit over the head for years about it.

So here's one for OpenCPN and anyone else to implement. The software is designed to run on a computer, rather than a dedicated instrument, right? And the vast majority of computers out there in personal hands these days, are some type of fairly current Windows OS, right? Well, every currently supported version of Windows has the native ability to run multiple displays. Just plug a second one in, tell the system what to do with it, and it works.

So how about making the software smart enough to do something that (sorry) is incredibly memory intensive? Like show my position on Screen#1 at this scale, and simultaneously show my position on Screen #2 at a different scale? No need to zoom in, zoom out, zoom zoom, just have two displays (why stop at two?) and have them each configured separately, for all parameters, in the software? Or, lock #2 into the overview, while I'm panning around in #1. No big deal.

In hindsight it is so obvious.(G) And if the user happens to have a 36" display at hand and wants to use that as the "overwatch" screen, so be it. Computers with four to eight cores, hell, even cell phones with four to eight cores, are common these days. Multiple displays, natively supported. So what's missing?

Yes, that's going to be one hell of a lot more overhead on the system, loading and moving multiple huge image maps and vector layers. So what? That's donkey work, and we've got some incredibly powerful donkeys these days.

It could mean splitting the program into two versions. One, resource intensive with multiple display options. The other, a lightweight that can run on minimal hardware. That's OK too.

Meanwhile I'll expect the new beta to be ready and on my desk, let's say, no later than 8AM Monday morning. Plenty of time for some trivial program changes.(VBG)

That's a good idea, but how many of us will have dual displays at the nav table?

How about this instead:

Make it possible to drag a tool along your route, and have the area around the tool appear several zooms higher in the other side of a split screen? Huh? That way you can see the whole route (or bigger pieces of it) on one side of the screen, and whatever closer detail you want on the other side. Would make it trivially easy to "fly" through a route and would make vector charts vastly more usable in a variety of different situations.

How well this would work would depend to some extent on screen real estate. Would be fantastic on dual displays (and much better than just running two instances of O at the same time), and would be very good on a biggish high res screen like my 22" 4K screen at my nav table.

[hellosailor]

Dockhead-
A split screen is the same thing as a dual display, whether it is two "windows" on one, or two windows on two physically separate devices. If I recall correctly, when NT got native support for multiple screens, it was all implemented in the hardware controls. The setup just maps memory from one huge virtual image, to different devices. Put 'em side-by-side and you can show one spreadsheet 36" wide. Tile them, or split them, as you will. The OS is busy just working with one image map. Some video cards used to have drivers that allowed for a "virtual desktop" bigger than the real one. AFAIK, this has been internalized into the NT OSes for something like a decade now.

Bart-
I thought it was pretty clear that running multiple instances would be a quick kludge that caused more problems than it solved, and that was indeed quite specifically not the question. So how's Lisa, still jamming on that sax?