bugGNU Octave - Bugs: bug #53753, Animation performance jumpy

 
 

bug #53753: Animation performance jumpy

Submitter:  Marshall <marsian>
Submitted:  Wed 25 Apr 2018 04:49:18 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Marsian Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 03 Mar 2019 06:32:24 PM UTC, comment #8: 

Since this slowdown has been "fixed" by the new default OpenGL driver. I'll close this report.

Pantxo Diribarne <pantxo>
Group Member
Mon 07 May 2018 05:12:38 PM UTC, comment #7: 

This may be related to or the effects magnified by bug #53845: I found that after changing the name of opengl32.dll as suggested there for 4.4.0, the performance improvement was enough to make it much smoother for 4.4.0 than 4.2.2, which looked smooth before (in comparison).

Marshall <marsian>
Thu 03 May 2018 07:21:47 PM UTC, comment #6: 

Thanks for the suggestion. I do create video sometimes using my own video record functions, but that doesn't allow rotating a 3D figure, or as much control that I can add through gui interfaces to jump to specific times/frames, arbitrary zoom in the time scale, control exact frame rates, forward, rewind and correlate jumping to a frame by clicking and/or dragging on a point in a different plot, etc. Actual video takes longer to generate before watching it than just starting the animation, but is often faster and smoother once generated.

Marshall <marsian>
Thu 03 May 2018 08:05:50 AM UTC, comment #5: 

I don't observe that default is faster than stable but as you say, even optimization options may have an influence.

As a workaround for animations, you may want to try and build your animations using getframe and the proposed patch for the "movie" function (see patch #9363). This should be faster and the animation can be viewed multiple times without having to redraw anyhing.

Pantxo Diribarne <pantxo>
Group Member
Thu 03 May 2018 05:28:29 AM UTC, comment #4: 

I notice that performance in the dev version (5.0.0 (hg id: 28641f4be5de))does not seem to have the same jumpiness as in 4.4.0. I wanted to try that first to double check that the problem was still there before I tried to apply the patch. So I'm not sure whether to try the patch or not.

I noticed that the severity was down-graded, but I think that if this is still a problem it is rather high priority for me. I think the jumpiness in 4.4.0 is even worse on my faster machine (I guess that it skips more frames because it is faster?). The smoothness is very important as I frequently use animations to visually validate important time dependent results, and a visual jump in a single frame has often been an indicator of a hidden problem. The "drawnow" function by definition is supposed to force a sync so that the code doesn't continue until the the plot has been updated/refreshed. In some cases I spend a lot of time making the animations as fast and smooth as possible, but is all wasted if I have to put in artificial delays to slow it down to ensure every frame gets drawn.

Marshall <marsian>
Thu 26 Apr 2018 11:39:15 AM UTC, comment #3: 

The attached preliminary patch make most Qt graphics operations synchronous and then "drawnow" works as expected. But as said this is very preliminary (there will be much work untill I am confident) and the patch may lead to dead locks in some situations. Anyway, I get pretty much the same results with FLTK and Qt and I'd be happy if you could give it a try.

(file #44035)

Pantxo Diribarne <pantxo>
Group Member
Wed 25 Apr 2018 07:18:30 PM UTC, comment #2: 

For Qt: i makes it to 64.140 on my system in 5 seconds.

Dan Sebald <sebald>
Wed 25 Apr 2018 06:28:05 PM UTC, comment #1: 

I think your assessment is fairly accurate Marshall.  Your example is very good for illustrating the issue, and I will elaborate.

The Qt toolkit has some timing issues, and recent modifications to the Qt figure code have solved some crash bugs

https://savannah.gnu.org/bugs/?53513

but I suspect the solutions have merely caused the problem to manifest in other ways.  As far as I understand the solutions, there are some delays introduced and some recursive-loop prevention constructs introduced.  In other words, I think that the recent changes in Qt toolkit will skip plotting a figure if it happens it is currently plotting a figure.

And to illustrate, examine your animation example with gnuplot and fltk toolkits.

For FLTK: There is no skipping of the plots, and the animation shows a "slowly" moving sine wave.  i makes it to 3.0100 on my system in 5 seconds.

For gnuplot:  Now gnuplot seems to have some issue where it is drawing a blank white screen in between plots (that should be fixed).  However, if one watches closely, they'll see a similar slowly moving sine wave.  So gnuplot toolkit behaves similar to FLTK toolkit, drawing every frame, as it were.  i makes it to 1.5700 on my system in 5 seconds.

For Qt:  Things are different.  Watch how far the sine wave moves in one plot.  It's an aliasing effect that gives the appearance of a sine wave that moves perhaps 20 times faster than the FLTK animation.  I suspect that Qt toolkit is skipping about twenty plots that it really shouldn't skip.  That is, in the time it takes to draw one plot (which is quite fast for Qt OpenGL implementation), the broader Octave executable in another thread is probably whirling through the loop and skipping 19 plots until the plotting thread resource is available again.

Maybe some day Qt toolkit will have a mutex which will coordinate the core thread and the plotting thread so that plotting isn't skipped.  I'd say mark as a duplicate bug.

Dan Sebald <sebald>
Wed 25 Apr 2018 04:49:18 PM UTC, original submission:  

In animating some plots I found that the performance in 4.3.91 was rather jumpy. It seemed to skip frames whereas other versions didn't. Maybe drawnow is not working properly? I tried the following in three versions of Octave (even simultaneously for side-by-side comparison without the if statement):


close all
figure(1)
x = 0:0.01:4*pi;
y = sin(x);
p = plot(x,y);
xlim(x([1,end]))
v = ver;
title(v(1).Version)
i = 0;
tic;
while 1
    i+=0.01;
    set(p,'ydata',sin(x+i));
    drawnow;
    %remove this 'if' for continuous animation
    if toc>5
        disp(i);
        break;
    endif
endwhile


The versions I used were: 
4.3.91 (hg id: ff59be58f028)
4.5.0+ (hg id: 55480087f125)
4.2.2

I found that 4.2.2 and 4.5.0+ ran smoothly, though 4.5.0 was significantly faster. 4.3.91 seemed to skip frames (and appeared to run slowly because of it). The following speed printouts resulted: 4.2.2 printed  5.1600, 4.5.0+ printed  33.460, and 4.3.91 printed 46.720. So 4.3.91 was technically faster, but seemed slowest because of the jumpiness because every frame wasn't shown.

Marshall <marsian>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44035:  blocking_qt_graphics.patch added by pantxo (7KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by marsian (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 -
    2019-03-03 pantxo StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2018-05-01 mtmiller CategoryPlotting Plotting with OpenGL
        Severity3 - Normal 2 - Minor
        Item GroupNone Performance
        StatusConfirmed Patch Submitted
        Release4.3.91 dev
        Operating SystemMicrosoft Windows Any
    2018-04-26 pantxo Attached File- Added blocking_qt_graphics.patch, #44035
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code