|
| From: | Doug Stewart |
| Subject: | Re: debugging GUI performance |
| Date: | Sun, 20 Oct 2013 11:28:26 -0400 |
On 10/20/2013 08:02 AM, Michael Goffioul wrote:
10/20/13On 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
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.
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.
Michael,
So I did that, and sure enough there are tens to hundreds of calls to draw_image as the mouse is moved over the canvas.
It seems that __fltk_redraw__ in __init_fltk__.cc:1860 is called whenever there is an event (like a mouse movement) in the FLTK window. __fltk_redraw__ then goes ahead and redraws each object in the figure including the axes and children. GUIs aren't really my area, but it seems like we should be checking the event type and possibly ignoring the trivial ones.
--Rik
Michael.
| [Prev in Thread] | Current Thread | [Next in Thread] |