bugGNU Octave - Bugs: bug #44959, Display coordinates of mouse...

 
 

bug #44959: Display coordinates of mouse cursor in QtHandles figures

Submitter:  Martin Kunz <mkunz>
Submitted:  Wed 29 Apr 2015 03:41:30 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 22 Jun 2015 09:48:26 PM UTC, comment #24: 

I pushed the patch with 5 significant figures on default:
http://hg.savannah.gnu.org/hgweb/octave/rev/062422f2e399

Closing report.

Pantxo Diribarne <pantxo>
Group Member
Sat 20 Jun 2015 01:05:11 PM UTC, comment #23: 

Right I can confirm ginput with "format long" works.

About the performance hit, the only tests I ran is to add a "windowbuttonmotionfcn" and see how it behaved with and without the patch. I used the following test function:


function tst ()
  toc ()
  tic ();
endfunction

set (gcf, "windowbuttonmotionfcn", @tst)
tic ()
plot(1:10)


Moving the mouse above the window then displays the time between two calls.
On my machine, the function is executed every ~0.4ms with or without the patch.

I'll push the patch by the end of the week-end

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jun 2015 07:20:43 PM UTC, comment #22: 

Well, it would be nice to have data-dependent precision, but that does sound like a project.  I think the current patch is enough of an improvement, even with default 6 digits of precision, to be applied.

Is there a way to verify that the additional callback overhead associated with every mouse movement does not excessively degrade performance?

Also, ginput() worked fine for me in getting the different values of the x-coordinates of the two peaks.  Needed to use 'format long' to see the difference in the returned values, but there was a difference.

Rik <rik5>
Group administrator
Thu 18 Jun 2015 02:51:20 PM UTC, comment #21: 

Precision based on zoomed range of data displayed? :)

John Donoghue <lostbard>
Group Member
Thu 18 Jun 2015 11:51:56 AM UTC, comment #20: 

"Un bon example vaut mieux que toutes les explications", would we say in French. Indeed, when zooming such a dataset you end up not being able to discriminate the x coordinates written using 4 digits.

Thoughs from others in view of the provided example?

BTW, trying to find a workaround I noticed that even "ginput" does not help which seams to me like a bug, not only an aesthetic point of view.


Pantxo Diribarne <pantxo>
Group Member
Thu 18 Jun 2015 11:08:37 AM UTC, comment #19: 

Sure! Please run the script in file #34253. You will see a nice sine half wave with apparently two glitches. By zooming in, it turns out that these are actually two pairs. Now you might want to get a clearer idea of how far away from each other the peaks are, both in x and y direction. The four digit coordinate display will not help here, six digits would be desirable. Of course, you can now plot the two regions in separate figures, with rescaling applied, but a precise coordinate display would make the task easier. As 7 digits are the technical limit for OpenGL, I suggest to print 7 or at least 6 digits.

Martin Kunz <mkunz>
Thu 18 Jun 2015 10:10:13 AM UTC, comment #18: 

@Martin:Qt uses the exact same opengl rendering class as fltk, the problem is not the gui toolkit but OpenGl.

If you zoom-in a plot to see points that have relative distance (i.e. (x1-x2)/x1) smaller than the opengl precision (~ 2e-7) you'll end up with points that are randomly placed as opengl is unable to compute their coordinates accurately using single precision (see bug #45271 , related to the previously cited bug). Trying to retrieve their coordinates with the mouse is of no use :-).

Can you propose a simple example script, using fltk, where mouse coordinates are not enough accurate?

Pantxo Diribarne <pantxo>
Group Member
Thu 18 Jun 2015 09:41:05 AM UTC, comment #17: 

@Pantxo: I was not sure if QtHandles uses single precision like fltk, but under these circumstances 7 digits would be a very reasonable decision. :-)

Screen resolution has nothing to do with this, as you can always zoom in to look at details of a curve. That is what I am doing when I want do explore a data set: I plot the whole set (which can span a large range that you cannot scale, say from 1 to 1e6) and then I zoom in to small regions where I am sometimes interested in small features (e.g +/-10 in my example).
This possibility for interactive data exploration is a great strength of Octave if you compare it for example to R, so I would love to see it emphasized by increasing the precision of the displayed coordinates.

Martin Kunz <mkunz>
Thu 18 Jun 2015 09:24:22 AM UTC, comment #16: 

@Martin: keep in mind that fltk/qt plots are opengl based so they basically use single precision floats (23 bits mantissa -> ~ 7 digits precision) to represent data, and 6 digits is not far from the best that we can do.

Due to the above limitation, it is currently necessary to scale data before representing them (see bug #32980): for example if you want to represent data ranging from x = 1e10 to x = 1.0001e10 you should represent (x - 1e10) if you want it to work as expected. This is an Octave limitation, but not what I wanted to show :-). Now you have data ranging from 0 to 1e6, but even if you maximize your figure window, data are represented on a 1000+ pixels screen ... the actual relative precision of the mouse pointer position is 1/1000 (or 1/3000 if your are rich), not 1e-6. Hence having 6 digits is of no use, 3 digits is not enough, 4 digits is the good compromise :-) 

Pantxo Diribarne <pantxo>
Group Member
Thu 18 Jun 2015 08:33:27 AM UTC, comment #15: 

I cannot test the patch, but I would like to add my thoughts about the question of precision of the displayed coordinates.
Do 6 digits hurt anybody? Probably not. However, I have regretted FLTKs lower precision several times, because I could not see the differences between two points of a curve in the coordinates. I do favour 6 digits!

This depends a lot on what you plot, but in case of real data you can easily be interested in what happens after the 4th digit. Take for example a 16bit analog to digital converter, which is nothing fancy nowadays. One least significant bit translates to a relative change of 0.000015, so you need 7 of those steps to see any difference in a 4 digit coordinate display.

Of course, someone using 24bit data might step forward now and demand 8 digits... Well, I'm not against it. ;-) But I understand that there are practical limits - a 2x15 digits display is annoying and needs too much space in the figure window. So what we need is a reasonable balance. For what I have seen so far, 6 digits would be a good compromise.

Martin Kunz <mkunz>
Thu 18 Jun 2015 08:23:15 AM UTC, comment #14: 

On Windows I see no different font + color than in the menu (tool)bars.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 18 Jun 2015 07:58:33 AM UTC, comment #13: 

@Rik:

I followed your suggestions for point 1 and 2 (agreed 6 digits for a 1000+ pixels screen is ridiculous). Now about the font and background color, I used the default and I am under the impression that the figure menus/toolbar also use the default (didn't find any customization in Figure.cc at least). 
I'll push a modified version of the patch soon.

Pantxo Diribarne <pantxo>
Group Member
Wed 17 Jun 2015 07:19:57 PM UTC, comment #12: 

I also like the patch from comment #10.  I think you can commit it to the dev branch and then we can start adding additional  features.

Other things:

1) The coordinates are displayed as [X.XXXXX; Y.YYYYY].  I would use a comma rather than a semicolon as the standard notation for a geometric point is (X, Y).

2) 6 significant figures is probably a bit much.  The FLTK toolkit displays only 4 digits which itself is probably too much, but definitely is better.  Can you reduce the output precision?

3) The toolbar background color seems to be different from the menubar background color.  Is this intentional?

4) The toolbar font seems to be different from the menubar font.  Is this intentional?

Rik <rik5>
Group administrator
Wed 17 Jun 2015 05:49:31 PM UTC, comment #11: 

Patch from comment #10 works fine, nice!

I'd prefer this status bar solution over a tooltip as:
1. it is unobtrusive
2. no extra action needed to display (X,Y)
3. it is the same as in the fltk toolkit.

Just my .02 $c

Philip Nienhuis <philipnienhuis>
Group Member
Tue 16 Jun 2015 07:35:33 PM UTC, comment #10: 

Forgot to attach the patch

(file #34236)

Pantxo Diribarne <pantxo>
Group Member
Tue 16 Jun 2015 07:32:27 PM UTC, comment #9: 

Hi,

I attached a patch that adds a status bar to the Qt figures and displays coordinates in the same fashion as in fltk figures.
For the time being I abandoned the idea of coordinates in tooltip and the status bar is not optional.

Can someone test it and give me feedback?

Pantxo Diribarne <pantxo>
Group Member
Sat 06 Jun 2015 06:27:13 PM UTC, comment #8: 

Thanks Pantxo for taking care of this.

I cannot test the patch as I have no build system, but from your description (mouse tooltip with on/off-switch) I would say it should work nicely. Just make sure that every user can find the feature easily, e.g. by having a menu entry AND a shortcut/modifier.

On the other hand showing the coordinates in a status bar should work well too, and feature would be visible to all users. You could then have a menu entry for hiding the status bar if you want more space for plotting.

In other words: +1 for both approaches.

Martin Kunz <mkunz>
Sat 06 Jun 2015 05:44:36 PM UTC, comment #7: 

Well I intended to make this mode optional, either by menu selection of using a modifier key (e.g. ctrl) when hovering the axes.

Pantxo Diribarne <pantxo>
Group Member
Sat 06 Jun 2015 03:14:26 PM UTC, comment #6: 

It's pretty cool, but I do find it distracting to have the mouse coordinates so big and prominent in the tooltip and following the pointer all around.  See what others think, but I would still prefer it to be placed somewhere more discrete like a toolbar.

Rik <rik5>
Group administrator
Sat 06 Jun 2015 09:05:27 AM UTC, comment #5: 

+1 for the tooltip :-)

Pantxo Diribarne <pantxo>
Group Member
Sat 06 Jun 2015 09:04:26 AM UTC, comment #4: 

Hi,

What about showing the mouse coordinates as mouse tooltip? It would avoid having to add a status bar at the bottom of Qt figures that are already large.

I attached a preliminary demo patch to show how it would look. Can you test and vote.


(file #34169)

Pantxo Diribarne <pantxo>
Group Member
Tue 05 May 2015 06:08:50 PM UTC, comment #3: 

+1

Hartmut <hardy>
Wed 29 Apr 2015 06:08:00 PM UTC, comment #2: 

Yes, that would be a good feature.  In the meantime, consider using ginput() if you need to get locations off a Qt plot precisely.

Rik <rik5>
Group administrator
Wed 29 Apr 2015 05:38:00 PM UTC, comment #1: 

+1

Philip Nienhuis <philipnienhuis>
Group Member
Wed 29 Apr 2015 03:41:30 PM UTC, original submission:  

Hi,

A feature I really miss when I am using the QtHandles graphics toolkit is to display the current coordinates of the mouse cursor while a figure window is in focus. The fltk toolkit has this (in the bottom line of every figure window) and I find it very handy to determine the position of a feature in a plot. Therefore it would be great to get similar functionality in the QtHandles toolkit.

Thanks for considering this,
Martin

Martin Kunz <mkunz>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34253:  fltkCoordinatePrecision.m added by mkunz (261B - text/plain)
file #34236:  qt_status_bar.patch added by pantxo (10KiB - text/x-diff)
file #34169:  tooltip_demo.patch added by pantxo (7KiB - text/x-diff)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by lostbard (added CC)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mkunz (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-06-22 pantxo StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2015-06-18 mkunz Attached File- Added fltkCoordinatePrecision.m, #34253
    2015-06-16 pantxo Attached File- Added qt_status_bar.patch, #34236
    2015-06-16 pantxo StatusConfirmed Patch Submitted
    2015-06-11 mtmiller Dependencies- bugs #45030 is dependent
    2015-06-06 pantxo Attached File- Added tooltip_demo.patch, #34169
    2015-05-23 lostbard Carbon-Copy- Added lostbard
    2015-04-29 mtmiller Severity3 - Normal 1 - Wish
        Release4.0.0-rc3 dev
    2015-04-29 rik5 StatusNone Confirmed
        Operating SystemMicrosoft Windows Any
        SummaryDisplay coordinates of mous cursor in QtHandles figures Display coordinates of mouse cursor in QtHandles figures

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code