bugGNU Octave - Bugs: bug #50750, OpenGL: Lines always appear above...

 
 

bug #50750: OpenGL: Lines always appear above patches for 2-D plots with zdata == []

Submitter:  Muhali <muhali>
Submitted:  Fri 07 Apr 2017 02:49:58 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 Aug 2017 10:22:29 AM UTC, comment #20: 

With the latest patch, the only performance hit is expected to be  when "zlimmode" is manual. Previously, when "zlimmode" was manual, there was no no check for children limits, while it is now necessary in order to determine if some children are 3D.
So the test (which I did not run) should be something like:


ii = 1:200;
axes ("zlimmode", "manual");
tic; arrayfun (@() patch (), ii); toc


Pantxo Diribarne <pantxo>
Group Member
Thu 10 Aug 2017 05:36:42 AM UTC, comment #19: 

What is a good way to benchmark?

I tried


x = rand (4, 200);
tic; plot (x); toc


But I don't see much difference between the layer3 and layer6 patches in terms of performance.

For the time being I pushed the latest layer6 patch because there are new bug reports about the behavior with light being incorrect.


Rik <rik5>
Group administrator
Tue 25 Jul 2017 01:38:03 PM UTC, comment #18: 

@Rik: Yes what you mention was expected but I thought the performance penalty was negligible. In fact it is not, rendering becomes up to 2 times slower for axes with ~200 objects.

I attached a new patch which is more elegant: the dimensionality of children objects is determined by comparing upper and lower z limits. The only drawback is that z limits have to be checked even when zlimmode is manual. I added a FIXME note about that but I think it is acceptable.

(file #41331)

Pantxo Diribarne <pantxo>
Group Member
Sat 22 Jul 2017 03:24:46 AM UTC, comment #17: 

I tried the patch and it works, however it looks like there is a performance penalty.  The function get_is2D is called from draw_axes which eventually requires a recursive search through the graphic objects to find any 3-D objects.  I inserted code to see how often draw_axes is called and it is quite frequent.  Try this patch


diff -r 560758754c57 libinterp/corefcn/gl-render.cc
--- a/libinterp/corefcn/gl-render.cc    Thu Jul 20 22:59:27 2017 +0200
+++ b/libinterp/corefcn/gl-render.cc    Fri Jul 21 20:22:55 2017 -0700
@@ -2110,6 +2110,9 @@ namespace octave

     // For 2D axes with only 2D primitives, draw from back to front without
     // depth sorting
+    static int num_calls = 0;
+    num_calls++;
+    std::cerr << "draw_axes: " << num_calls << std::endl;
     bool is2D = props.get_is2D (true);
     if (is2D)
       glDisable (GL_DEPTH_TEST);
diff -r 560758754c57 libinterp/corefcn/graphics.cc
--- a/libinterp/corefcn/graphics.cc     Thu Jul 20 22:59:27 2017 +0200
+++ b/libinterp/corefcn/graphics.cc     Fri Jul 21 20:22:55 2017 -0700
@@ -4572,6 +4572,10 @@ has_3D_primitive (const graphics_handle&
   if (! go.valid_object ())
     return retval;

+    static int num_calls = 0;
+    num_calls++;
+    std::cerr << "has_3D: " << num_calls << std::endl;
+
   if (go.isa ("figure") || go.isa ("axes")
       || go.isa ("hggroup") || go.isa ("uipanel"))
     {


After re-compiling try some plot commands and try toggling the grid or panning the plot.  There are ~2 has_3D_primitive calls for every draw_axes call.


Rik <rik5>
Group administrator
Thu 20 Jul 2017 09:22:24 PM UTC, comment #16: 

I attached a cset that fixes the regression for me.

(file #41268)

Pantxo Diribarne <pantxo>
Group Member
Tue 06 Jun 2017 05:32:39 PM UTC, comment #15: 

I just noticed that now 2D representations of 3D scenes fail on-screen and in printout: see e.g. demo light 2.

The reason is that we currently determine wether an axes is 2D using only the "view" property, which may be setup as 2D even when there are 3D primitives in the axes. I'll provide a fix ASAP.

Pantxo Diribarne <pantxo>
Group Member
Sun 04 Jun 2017 09:07:57 PM UTC, comment #14: 

Thanks Rik, I pushed the patched here:

http://hg.savannah.gnu.org/hgweb/octave/rev/06805aabbdd1

Closing report as fixed.

Pantxo Diribarne <pantxo>
Group Member
Sun 04 Jun 2017 02:55:21 PM UTC, comment #13: 

I did test it quickly last week.  I think it is worth applying as it narrows the number of cases where Octave is wrong to something smaller.

Rik <rik5>
Group administrator
Sun 04 Jun 2017 02:54:44 PM UTC, comment #12: 

I did test it quickly last week.  I think it is worth applying as it narrows the number of cases where Octave is wrong to something smaller.

Rik <rik5>
Group administrator
Sun 04 Jun 2017 12:34:01 PM UTC, comment #11: 

@Rik: did you get a chance to test the patch?

Pantxo Diribarne <pantxo>
Group Member
Sun 28 May 2017 12:40:25 PM UTC, comment #10: 

@Rik: I attached an updated cset that takes care of the "layer" property. Unfortunately gl2ps does not provide a way to change the sorting algorythm on a per viewport basis. So after the patch, the bug still stands for printed output if there is a 3D axes among other 2D axes e.g


subplot (1,2,1)
sombrero ()
subplot (1,2,2)
patch ()
line (0:.1:1, 1:-.1:0, "marker", "o", "markerfacecolor", "r", "color", "r")
print /tmp/toto.png


(file #40803)

Pantxo Diribarne <pantxo>
Group Member
Sun 28 May 2017 04:39:38 AM UTC, comment #9: 

@Pantxo: Ping!  Just checking that you saw my note from May 18th.  It looks to me like if we are going to support the 'layer' property of axes, and use this patch, that we would need to change the order of drawing axes and children in gl-render.cc.

Rik <rik5>
Group administrator
Thu 18 May 2017 05:05:55 PM UTC, comment #8: 

@Pantxo: I tried your patch and it definitely resolves the issues experienced.  I think it is probably the right direction, but it needs some refinement.  On 3-D plots that are presented as 2-D plots, such as contourf or autumn, the axes ticks are now underneath the patch object rather than above.

Try


demo autumn
OR
demo contourf 1


to see what I mean.

The problem seems to be that the axes "layer" property which can be "top" or "bottom" is no longer working.

Rik <rik5>
Group administrator
Wed 12 Apr 2017 09:48:18 PM UTC, comment #7: 

"demo hold 6" also shows the problem (see here: https://josoansi.de/octave_plot_compare/compare_plot_demos_03.html)

I attached a simple preliminary patch that fixes this bug and the "hold" demo, but didn't test it thoroughly against regressions.

(file #40382)

Pantxo Diribarne <pantxo>
Group Member
Fri 07 Apr 2017 10:30:56 PM UTC, comment #6: 

It's all the same issue.  Every line is being displayed above the patch object.  That includes the ones you want (circle and horizontal line) and the ones you don't want (vertical line).

Rik <rik5>
Group administrator
Fri 07 Apr 2017 10:11:57 PM UTC, comment #5: 

but note that the horizontal line and the circle (median and mean I guess) SHOULD be visible.

Muhali <muhali>
Fri 07 Apr 2017 09:37:07 PM UTC, comment #4: 

I added a simpler example of a single line and a rectangle object (tst_rect.m).  It shows that lines are always on top of patches for 2-D OpenGL plots.

(file #40324)

Rik <rik5>
Group administrator
Fri 07 Apr 2017 09:09:59 PM UTC, comment #3: 

I changed the sample test file to not load the package nan.  This script is attached to the bug report as tst_boxplot.m.  It also requires a version of 'aboxplot.m' that does not use nanmean.  That is also uploaded.

Using Qt, I find that the dots are visible onscreen.  This probably indicates that the effect depends on the particular version of OpenGL on a user's computer and whether it is being hardware accelerated or not.

When I print, I get two different results depending on whether gl2ps version 1.3.9 or 1.3.8 is used.  With the more recent version, 1.3.9, the print out matches the screen, but that does have the dots on it.

I'm attaching the two plots: foo.1.3.9.png and foo.1.3.8.png.



(file #40320, file #40322,

Rik <rik5>
Group administrator
Fri 07 Apr 2017 05:24:38 PM UTC, comment #2: 

Yes, no dots (screenshot) is the figure window from the plot command and is as expected, and foo.png is the incorrect print output with the dots visible.

Muhali <muhali>
Fri 07 Apr 2017 05:09:03 PM UTC, comment #1: 

Just checking, foo.png is output from Octave which is incorrect.  And Screenshot.png is what the output should look like?

Rik <rik5>
Group administrator
Fri 07 Apr 2017 02:49:58 PM UTC, original submission:  

The following is adapted from the aboxplot function (attached)


x1 = normrnd(5,2,10000,1);
x2 = normrnd(10,2,10000,1);
x3 = normrnd(15,2,10000,1);

pkg load nan
x{1}{1} = x1;
x{1}{2} = x2;
x{1}{3} = x3;

graphics_toolkit qt

aboxplot(x,'labels',[5,10,15]);
xlabel('\mu');
print foo.png


In the box there should be no dots visible, as in Matlab. In octave I get

with qt: dots not in plot but in print (see attached plot and print)

with fltk: dots in plot and print

with gnuplot: no dots in plot and print

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #41331:  layer6.patch added by pantxo (7KiB - text/x-patch)
file #41268:  layer3.patch added by pantxo (5KiB - text/x-patch)
file #40803:  layer.patch added by pantxo (5KiB - text/x-patch)
file #40382:  depth.patch added by pantxo (2KiB - text/x-patch)
file #40324:  tst_rect.m added by rik5 (244B - text/x-objcsrc)
file #40320:  tst_boxplot.m added by rik5 (209B - text/x-objcsrc)
file #40321:  foo.1.3.9.png added by rik5 (14KiB - image/png)
file #40322:  aboxplot.m added by rik5 (10KiB - text/x-objcsrc)
file #40323:  foo.1.3.8.png added by rik5 (13KiB - image/png)
file #40308:  foo.png added by muhali (12KiB - image/png)
file #40309:  aboxplot.m added by muhali (10KiB - text/x-objcsrc)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by muhali (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 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-10 rik5 Dependencies- bugs #51716 is dependent
    2017-07-25 pantxo Attached File- Added layer6.patch, #41331
    2017-07-20 pantxo Attached File- Added layer3.patch, #41268
    2017-06-04 pantxo StatusPatch Reviewed Fixed
        Open/ClosedOpen Closed
    2017-05-28 pantxo Attached File- Added layer.patch, #40803
    2017-05-18 rik5 StatusPatch Submitted Patch Reviewed
    2017-04-12 pantxo Attached File- Added depth.patch, #40382
        StatusConfirmed Patch Submitted
    2017-04-07 rik5 Attached File- Added tst_rect.m, #40324
        StatusNeed Info Confirmed
        Summarydots behind box OpenGL: Lines always appear above patches for 2-D plots with zdata == []
    2017-04-07 rik5 Attached File- Added tst_boxplot.m, #40320
        Attached File- Added foo.1.3.9.png, #40321
        Attached File- Added aboxplot.m, #40322
        Attached File- Added foo.1.3.8.png, #40323
    2017-04-07 rik5 StatusNone Need Info
    2017-04-07 muhali Attached File- Added Screenshot from 2017-04-07 12-45-57.png, #40307
        Attached File- Added foo.png, #40308
        Attached File- Added aboxplot.m, #40309

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code