Re: debugging #39925

[Rik]

On 10/19/2013 10:00 AM, address@hidden wrote:
> Message: 6
> Date: Sat, 19 Oct 2013 10:27:28 -0400
> From: Doug Stewart <address@hidden>
> To: Octave Maintainers List <address@hidden>
> Subject: debugging #39925
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
>  hg id
> 93e272018df2 tip
>
> Ubuntu 10.04
>
> ../configure FFLAGS=-g CFLAGS=-g CXXFLAGS=-g --disable-gui
> The GUI does not respond to CONTROL C
>
> While trying to debug #39925 I found something that might or might not be
> related to this bug.
>
> from the octave prompt I am running:
>
>
>
> In gdb I
> have  breakpoint #1 at  gl-render.cc:1400   ( draw_axes)
>    and breakpoint #2 at  gl-render.cc:2613   (draw_image)
>
> The first Time I run
> image (1e7  + [1 2], 1 + [1 2], rand (2));
>
> the break points are :  1 2 1 2
> The second time I run the same image
> the break points are: 1 2 2
> the 3rd time it is : 1 2 2 2
> the 10th time it is: 1 2 2 2 2 2 2 2 2 2 2
> Etc.
>
> The reason that I saw this is that this bug (#39925) does not happen on the
> first run  so I was trying multiple runs, and saw this behaviour.
>
> If you run the image command for the 20th time there is no need to  run
> draw_image 20 times.
>
> If we figure out why this is happening then we might also solve bug #39925
> Doug
10/20/13

Doug,

Some interesting things are going on with this bug.  Entirely separately,
I've checked in changes to image.m and imagesc.m in the last few days.  And
now when I go back to try and replicate the segfault in the bug report I can't.

On the other hand, it seems like we have a huge performance issue.  I set a
breakpoint at opengl_renderer::draw_image in gl-render.cc and it is hit
every time the mouse moves in the FLTK window.  I checked with other base
graphic objects like surface and line and it is the same thing.  Frankly,
I'm surprised that our graphic performance isn't extremely slow as we seem
to be re-calculating and re-drawing all the time.  Maybe OpenGL is saving
us by efficiently noticing that nothing has changed.  Still, for surfaces
anyways, we actually go through each vertex and find the NaN and Inf values
and implement clipping and this is done every time the mouse moves.

--Rik