[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debugging #39925

From: Michael Goffioul
Subject: Re: debugging #39925
Date: Sun, 20 Oct 2013 11:02:05 -0400

On Sun, Oct 20, 2013 at 10:49 AM, Rik <address@hidden> wrote:
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:
>       <CAAohRsYu0jgbiXMfLmL5yGQmxXRxUZzKjG4bYMWW3g5Yu=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


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.

Placing breakpoints in paint events can be tricky, and it's possible that the breakpoint is hit only because you're actually doing debug (breakpoint is hit -> type "continue" at gdb prompt -> move back to the figure window -> paint event -> breakpoint is hit -> ...; but the paint event wouldn't happen if you hadn't hit the breakpoint in the first place).

So if you want to be sure you're getting a paint event every time you move the mouse, put a "printf" statement in draw_image instead of interrupting the program execution.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]