bugGNU Octave - Bugs: bug #53087, getframe not always rendering 3D...

 
 

bug #53087: getframe not always rendering 3D surfaces properly

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Wed 07 Feb 2018 12:28:57 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
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

Tue 27 Feb 2018 09:09:59 AM UTC, comment #19: 

Thanks Philip for testing. The patch has been pushed and I can't see the original issue anymore. Closing report as fixed.

Pantxo Diribarne <pantxo>
Group Member
Fri 23 Feb 2018 10:31:04 AM UTC, comment #18: 

Run fine on win10 as well (as expected, but just to be sure)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 23 Feb 2018 09:35:26 AM UTC, comment #17: 

@Philip: good news! The errors you see are expected, this is because the corresponding functions have demos that don't produce figures. I didn't look at the warnings yet but I am pretty sure we have the same on linux, so that is not Windoze specific.

Pantxo Diribarne <pantxo>
Group Member
Fri 23 Feb 2018 07:43:27 AM UTC, comment #16: 

Hey... good to now....:
clicking "preview" wipes attachments from comments.

Another Savannah bug :-(

(file #43387)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 23 Feb 2018 07:41:29 AM UTC, comment #15: 

and you can do something else on your computer :-).
... like having breakfast next to my computer (crossbuild just finished overnight).

Seriously;
On win7 the example script works w/o crashes, the dump-plot_demo script ploughed steadily through until the end.
The diary shows some errors and warnings, I attached it.

I'll try on win10 later.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 22 Feb 2018 09:56:38 PM UTC, comment #14: 

@Philip: Cool, a useful (and severe) test would be to try and run the dump_plot_demo script I posted in bug #53186. It'll takes some time but if it works you wont see figures popping up and you can do something else on your computer :-).

Pantxo Diribarne <pantxo>
Group Member
Thu 22 Feb 2018 09:33:28 PM UTC, comment #13: 

AFAIK Rik has only XP. But I agree that for this case XP will probably do.
I'll try on win7 & win10 anyway.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 22 Feb 2018 09:28:23 PM UTC, comment #12: 

@Philip: Rik has already confirmed that it seems to work on Windows.

Pantxo Diribarne <pantxo>
Group Member
Thu 22 Feb 2018 09:25:49 PM UTC, comment #11: 

@Panxto
I overlooked the bug #53186 patch (and had little time this week), I'll try later.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 20 Feb 2018 11:27:35 AM UTC, comment #10: 

@Philip: do you have some time to test the patch in bug #53186. On linux it works well and allows for invisible Qt figures to be printed, and it also solves the original problem in this bug report with getframe. Hopefully, it can avoid the crash you observe.

Pantxo Diribarne <pantxo>
Group Member
Sun 11 Feb 2018 07:10:09 PM UTC, comment #9: 

yep, triggers a crash/segfault.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 11 Feb 2018 06:45:22 PM UTC, comment #8: 


>> osmesa?


Yes, getframe makes use of osmesa's pixel output when a figure is not visible. On Windows osmesa is present but not functional, hence the try/catch in getframe.

Does the following trigger a crash?


plot (1:10)
try
  a = __osmesa_print__ (gcf);
catch
  error ("No functional osmesa")
end


If so that is a regression on Windows I think.

Pantxo Diribarne <pantxo>
Group Member
Sat 10 Feb 2018 05:23:47 PM UTC, comment #7: 

osmesa?
Maybe there's a connection with the SW opengl driver (my mxe-octave tree is configured with --disable-system-opengl)

Philip Nienhuis <philipnienhuis>
Group Member
Sat 10 Feb 2018 07:30:46 AM UTC, comment #6: 

Thanks Philip. So it looks like it is an opengl driver specific issue.

As for osmesa on windows, I didn't expect it to crash Octave. It used to produce an error isn't it?

Pantxo Diribarne <pantxo>
Group Member
Fri 09 Feb 2018 07:16:36 PM UTC, comment #5: 

But with a visible frame, getframe produces the attached pic.

I see little or no difference with the on-screen graphic.


Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Feb 2018 07:11:50 PM UTC, comment #4: 

A brandnew crossbuild crashes on the command:

:
frame2  = getframe (gcf); ## make use of osmesa

As getframe works with visible plots, I think this is an osmesa bug, right?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Feb 2018 05:16:43 PM UTC, comment #3: 

I'll have look. Just cross-building now, report later.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Feb 2018 09:29:24 AM UTC, comment #2: 

@Philip: since you have been involved in testing getframe when it was added, I though you migh also help here. I'd like to know if this bug also happens on Windows (with visible figures only, since osmesa doesn't work on Windows). Thanks in advance.

Pantxo Diribarne <pantxo>
Group Member
Fri 09 Feb 2018 09:27:07 AM UTC, comment #1: 

Adding Phillip to request testing on windows.

Pantxo Diribarne <pantxo>
Group Member
Wed 07 Feb 2018 12:28:57 PM UTC, original submission:  

As an example see the following example:


demo light 2
frame  = getframe (gcf); ## make use of glReadPixels
set (gcf, "visible", "off");
frame2  = getframe (gcf); ## make use of osmesa
imwrite (frame.cdata, "frame_visible.png")
imwrite (frame2.cdata, "frame_invisible.png")
open frame_visible.png
open frame_invisible.png


I attached the resulting png files. When the figure is visible, getframe makes use of glReadPixels and some primitives are simply not drawn. When the figure is invisible, getframe makes use of osmesa pixel buffer and all primitives are drawn properly.

Pantxo Diribarne <pantxo>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #43387:  diary_win7.log added by philipnienhuis (30KiB - application/octet-stream)
file #43199:  frame_invisible.png added by pantxo (14KiB - image/png)
file #43200:  frame_visible.png added by pantxo (14KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo
  • -email is unavailable- added by pantxo (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-27 pantxo StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2018-02-23 pantxo StatusNone In Progress
    2018-02-23 philipnienhuis Attached File- Added diary_win7.log, #43387
    2018-02-09 philipnienhuis Attached File- Added frame_visible.png, #43218
    2018-02-09 pantxo Carbon-Copy- Added -email is unavailable-
    2018-02-07 pantxo Attached File- Added frame_invisible.png, #43199
        Attached File- Added frame_visible.png, #43200

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code