You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, on my machine, the surface plot seems to have multiple issues. If I run the following code:
#include<arrayfire.h>intmain(int argc, char *argv[])
{
try {
af::info();
af::array X = af::seq(0., 0.4, 0.1);
af::array Y = af::seq(0., 0.9, 0.1);
af::array Z = af::constant(1., 5, 10);
af::Window window(1500, 800, "The door.");
do {
window.surface(X, Y, Z, "The weird surface");
} while(!window.close());
} catch (af::exception& e) {
fprintf(stderr, "%s\n", e.what());
throw;
}
return0;
}
I see the following image (without the red lines):
The image has a few problems:
The Y-axis labels are all the same.
The X-axis labels are probably all the same as well.
The surface is plotted in wrong position and probably scaled badly (hard to say).
System version:
ArrayFire v3.6.0 (OpenCL, 64-bit Linux, build default)
[0] INTEL: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 15930 MB
Linux pine 4.13.11-1-ARCH #1 SMP PREEMPT Thu Nov 2 10:25:56 CET 2017 x86_64 GNU/Linux
Both Forge from devel branch and from arrayfire behave the same, CPU backend as well.
Also when I resize the window, the program crashes with:
Failed to blit
[1] 788 segmentation fault (core dumped) ./a.out
Thank you for your help and for a nice high-performance visualization tool!
@FloopCZ We will look into it and update here as soon as we find something. Unfortunately, I can't give an ETA on this, but I will try to look into it as soon as possible.
@FloopCZ This seems to be an issue inside ArrayFire while auto-calculating the axes limits. I have raised an issue in the downstream(ArrayFire) project and you can follow its progress over there.
As far as the window crash upon resize, I am unable to replicate this on my end. The window seems to be resizing just fine for me.
As a work around for the render, you can use the following code to explicitly set the chart axes yourselves so that you are not effected by the auto-calculation.
af::info();
af::array X = af::seq(0., 0.4, 0.1);
af::array Y = af::seq(0., 0.9, 0.1);
af::array Z = af::constant(0., 5, 10);
af::Window window(1500, 800, "The door.");
window.setAxesLimits(0.0f, 0.4f, 0.0f, 0.9f, -1.0f, 1.0f, true);
@9prady9 Am able to reproduce window resize issue on Ubuntu 16.04. Appears to be an issue with glbinding.
Starting program: /home/arrayfire/forge/build/examples/cpu/field
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Failed to blit
Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
35 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
#1 0x00007fffeea35064 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2 0x00007fffeea35275 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3 0x00007fffeea35612 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4 0x00007fffeea3d7f4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5 0x00007fffeea3da29 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#6 0x00007fffeea0e1db in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#7 0x00007fffee7d6cb8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8 0x00007fffee7d6f18 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9 0x00007fffee84b405 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#10 0x00007fffee84c4d8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#11 0x00007fffee84dbe5 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#12 0x00007fffeea37ce5 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#13 0x00007fffee7662e7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#14 0x00007fffee766462 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#15 0x00007ffff629f8aa in (anonymous namespace)::BasicCallHelper<void, int, int, int, int, gl::GLenum, gl::GLenum, void*>::call(const glbinding::Function<void, int, int, int, int, gl::GLenum, gl::GLenum, void*> *, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f887>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f88c>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f891>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f896>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f89b>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f8a0>, <unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f8a5>) (function=0x7ffff67fd1a0 <glbinding::Binding::ReadPixels>,
arguments#0=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f887>, arguments#1=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f88c>,
arguments#2=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f891>, arguments#3=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f896>,
arguments#4=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f89b>, arguments#5=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f8a0>,
arguments#6=<unknown type in /usr/lib/libglbindingd.so.2, CU 0xa21538, DIE 0xa3f8a5>) at /build/libglbinding-K9IIU3/libglbinding-2.1.3+519~ubuntu16.04.1/source/glbinding/include/glbinding/Function.inl:21
#16 0x00007ffff62aea7e in glbinding::Function<void, int, int, int, int, gl::GLenum, gl::GLenum, void*>::call (this=0x7ffff67fd1a0 <glbinding::Binding::ReadPixels>, arguments#0=@0x7fffffffd54c: 0,
arguments#1=@0x7fffffffd548: 0, arguments#2=@0x7fffffffd544: 640, arguments#3=@0x7fffffffd540: 480, arguments#4=@0x7fffffffd53c: <incomplete type>, arguments#5=@0x7fffffffd538: <incomplete type>,
arguments#6=@0x7fffffffd560: 0x0) at /build/libglbinding-K9IIU3/libglbinding-2.1.3+519~ubuntu16.04.1/source/glbinding/include/glbinding/Function.inl:171
#17 0x00007ffff62ae2da in glbinding::Function<void, int, int, int, int, gl::GLenum, gl::GLenum, void*>::operator() (this=0x7ffff67fd1a0 <glbinding::Binding::ReadPixels>, arguments#0=@0x7fffffffd54c: 0,
arguments#1=@0x7fffffffd548: 0, arguments#2=@0x7fffffffd544: 640, arguments#3=@0x7fffffffd540: 480, arguments#4=@0x7fffffffd53c: <incomplete type>, arguments#5=@0x7fffffffd538: <incomplete type>,
arguments#6=@0x7fffffffd560: 0x0) at /build/libglbinding-K9IIU3/libglbinding-2.1.3+519~ubuntu16.04.1/source/glbinding/include/glbinding/Function.inl:147
#18 0x00007ffff62996c2 in gl::glReadPixels (x=0, y=0, width=640, height=480, format=<incomplete type>, type=<incomplete type>, pixels=0x0)
at /build/libglbinding-K9IIU3/libglbinding-2.1.3+519~ubuntu16.04.1/source/glbinding/source/gl/functions_r.cpp:181
#19 0x00007ffff7ada8ea in forge::wtk::Widget::swapBuffers (this=0x93bb10) at /home/arrayfire/forge/src/backend/opengl/glfw/window.cpp:244
#20 0x00007ffff7ad5913 in forge::opengl::window_impl::draw (this=0x9209d0, pRenderable=std::shared_ptr (count 2, weak 0) 0xf1f7a0) at /home/arrayfire/forge/src/backend/opengl/window_impl.cpp:272
#21 0x00007ffff7afe758 in forge::common::Window::draw (this=0x820cc0, pChart=0xf66830) at /home/arrayfire/forge/src/backend/common/window.hpp:116
#22 0x00007ffff7afc8c4 in fg_draw_chart (pWindow=0x820cc0, pChart=0xf66830) at /home/arrayfire/forge/src/api/c/window.cpp:239
#23 0x00007ffff7b11b69 in forge::Window::draw (this=0x7fffffffdca0, pChart=...) at /home/arrayfire/forge/src/api/cpp/window.cpp:130
#24 0x0000000000402a79 in main () at /home/arrayfire/forge/examples/cpu/field.cpp:82
Activity
9prady9 commentedon Nov 22, 2017
@FloopCZ We will look into it and update here as soon as we find something. Unfortunately, I can't give an ETA on this, but I will try to look into it as soon as possible.
FloopCZ commentedon Dec 3, 2017
Thank you @9prady9. :-)
9prady9 commentedon Dec 4, 2017
@FloopCZ This seems to be an issue inside ArrayFire while auto-calculating the axes limits. I have raised an issue in the downstream(ArrayFire) project and you can follow its progress over there.
As far as the window crash upon resize, I am unable to replicate this on my end. The window seems to be resizing just fine for me.
As a work around for the render, you can use the following code to explicitly set the chart axes yourselves so that you are not effected by the auto-calculation.
FloopCZ commentedon Dec 8, 2017
@9prady9 Thank you for the workaround, I have just tried it. Unfortunately, the image still has similar problems. This is what I see:

9prady9 commentedon Dec 8, 2017
Looks like transformation is off, I will look into it in forge.
mlloreda commentedon Apr 10, 2018
@9prady9 Am able to reproduce window resize issue on Ubuntu 16.04. Appears to be an issue with glbinding.
9prady9 commentedon Apr 18, 2019
Updates related to fix for auto-calculation of surface limits will be provided on arrayfire/arrayfire#2006 as it is related to arrayfire code base.
Surface transformation issue will be bug handled in this issue.