20

Consider the following code which draws a figure:

figure('Renderer', 'opengl');
N = 50;
tL = linspace(0.5, 6, N).';
tB = sort(randi(100,N,20),1);
yyaxis right; plot(tL, tB);
xlim([2 6]);

When I run this code, I get a haunted figure with moving lines that should be static, for example (this one is using my real data which looks a bit nicer than the example):

enter image description here

Several additional observations:

  • I noticed that without the xlim line nothing happens (i.e. the figure is static as expected).
  • I couldn't get it to work on another computer running the same MATLAB version.
  • The line "animation" seems to coincide with the appearing and disappearing of the axes' toolbar (the one on the top right with the zoom etc.).
  • When I create the figure using figure('Renderer', 'painters') this doesn't happen.

Can somebody please explain why this is happening? Is this documented behavior? Any idea how to control it?

I'm working with R2018b on Windows 10 v1803. My screens are connected to the on-board GPU which is Intel HD Graphics 530 (driver version 22.20.16.4749).

September 2019 Update: This also happens for me on R2019b on Windows 10 v1903. As suggested in the comments, below is the output of opengl info:

                          Version: '4.5.0 - Build 25.20.100.6373'
                           Vendor: 'Intel'
                         Renderer: 'Intel(R) HD Graphics 530'
            RendererDriverVersion: '25.20.100.6373'
        RendererDriverReleaseDate: '18-Nov-2018'
                   MaxTextureSize: 16384
                           Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buffer, Antialias 8 samples)'
                         Software: 'false'
             HardwareSupportLevel: 'full'
        SupportsGraphicsSmoothing: 1
    SupportsDepthPeelTransparency: 1
       SupportsAlignVertexCenters: 1
                       Extensions: {223×1 cell}
               MaxFrameBufferSize: 16384
Dev-iL
  • 22,722
  • 7
  • 53
  • 89
  • 1
    This phenomenon that the rendering is slow is the most probable cause. – OmG Jan 09 '19 at 10:10
  • I **can** reproduce it in MATLAB 2018b, win 10x64, NVIDIA GTX 1050 – Ander Biguri Jan 09 '19 at 10:27
  • 1
    I **cannot** reproduce it in MATLAB 2018b, Ubuntu 17, NVIDIA GTX 1080 Ti. – Ander Biguri Jan 09 '19 at 10:32
  • I **cannot** reproduce it in MATLAB 2017a, win 10x64, NVIDIA GTX 1050 – Ander Biguri Jan 09 '19 at 13:29
  • 6
    Did you submit a bug report to the MathWorks? I'm not sure what kind of answer you expect... Cool effect though! :) – Cris Luengo Jan 09 '19 at 15:17
  • 4
    I'd like to know how to control it. Would be nice to be able to add this motion effect to dashed/dotted lines in other plots. – Dev-iL Jan 14 '19 at 13:26
  • The code seems inconsistent with your figure. In the figure you have values of magnitude of 10^9, but the code tB = sort(randi(100,N,20),1); generates random values less than 100? – uPhone Mar 27 '19 at 15:05
  • @uPhone I mentioned in the question that: _this {animation} is using my real data which looks a bit nicer than the example {ones}_. The values don't matter for the purpose of this question, and the same issue happened on my system with the random values too. Also, I should mention that this doesn't happen on the newer R2019a. – Dev-iL Mar 27 '19 at 15:17
  • @Dev-iL Okay, I see. I have no such issues with MATLAB 2018a on my Macbook Air 2013. – uPhone Mar 27 '19 at 18:16
  • @Dev-iL, what is the output of `>> opengl info`? – Enlico Sep 22 '19 at 14:00
  • However, I **can** reproduce it in MATLAB R2019a on Arch Linux. – Enlico Sep 22 '19 at 14:04
  • You can create a service request here: https://www.mathworks.com/support/contact_us.html – Enlico Sep 22 '19 at 14:43
  • I cannot reproduce this on R2018b or on R2019b on Windows 10. What happens when you open the figure with the settings ...'ToolBar','none','MenuBar','none'); ? – Lucademicus Jan 02 '20 at 07:25
  • @Lucademicus Unfortunately, I cannot say at the moment, because it doesn't happen on my R2019b anymore (my version is a bit newer now - `9.7.0.1261785 (R2019b) Update 3`; although I haven't seen anything in the release notes to indicate this was changed). If I manage to reproduce it again I'll be sure to update. Thanks for the suggestion though! – Dev-iL Jan 02 '20 at 08:49
  • @Dev-iL frustrating that we're not able to reproduce this glitch. I must say that the effect looks familiar, but I'm not sure when/how I've seen it. I think I've seen it when resizing figures, so probably OmG's remark about the plotting being slow makes sense? I noticed the toolbar is visible 3 times (at the end of the gif), is that an artifact of the gif? – Lucademicus Jan 02 '20 at 11:46
  • @Lucademicus Indeed (regarding: frustrating, gif artifact). As for the plotting speed - I'm skeptical about that, and even if this is the case - the question remains - is there anything that can be done {to speed it up or slow it down} to get/remove this effect? – Dev-iL Jan 02 '20 at 12:09
  • @Dev-iL I meant that the plotting speed as cause would only make sense if the plotting is _really_ slow. But you're right that up to this point we could classify this as 'erratic behavior'. Perhaps a service request would help? – Lucademicus Jan 02 '20 at 12:15
  • @Lucademicus Alas, I don't require any service from TMW; whether they fix it or keep it is all the same to me - I mainly want to understand what's going on, and if there's some undocumented feature hiding in here, I'd like to know about it :) – Dev-iL Jan 02 '20 at 12:24
  • you must have some other code or setting that affect your plots because a plot call render the figure with grey areas around it unless you specify (set(gcf, 'color', 'white') I do hate this when I review papers ... in my system case (Win10, R2016b, AMD Radeon (TM) R7 M370 with driver 4.5.13559 Compatibility Profile Context 26.20.12028.2) the tB is not plotted in light blue (from the left axis color). Finally the rendered data does not have the round shape you get ... interesting to see – bhamadicharef Jul 20 '20 at 01:19
  • 1
    @bhamadicharef you can see from the comments that others managed to reproduce the problem with just the code provided. Regardless, this doesn't happen in older MATLAB versions, which don't have an animated axes toolbar (I believe the version you're using falls into this category). – Dev-iL Jul 20 '20 at 03:45

1 Answers1

1
  • Firstly, you should understand that a figure is not a static picture at all. It refreshes frequenctly. If one resize/move the container(figure), the figure will be redrawed just after the interaction.
  • Secondly, All objects,including lines,annotations,legend... , are redrawed at the same time. The discontinuous line types will be captured easily. This why you could see a "animated" dashed line.
  • Lastly, for matlab, there are some interaction differences on Linux/Mac and Windows. On Windows, Move Mouse on figure will not fire data tracking event. But on Linux, the Data Tracker will be activated on Mouse move. Events for data tracking, object selection etc will refresh the plot.

All in all, the "animation" you see is designed by the author, and it should be.

The following code disabled the current axes's hit test visibility, so the redraw event won't be fired during mouse move or click on axes. But with the resize event, all objects must be redraw (which is a intentionally designed behaviour).

figure('Renderer', 'opengl');
N = 50;
tL = linspace(0.5, 6, N).';
tB = sort(randi(100,N,20),1);
yyaxis right; h = plot(tL, tB,'ButtonDownFcn',@lineCallback); 
set(gca,'HitTest','off')
xlim([2 6]);

function lineCallback(Figure1,Structure1)
    disp('Button Down: redraw...'); 
end

This code snippet has been tested using MATLAB R2018B on Mac,window10 and Ubuntu 18.04. All works fines.

Shannon
  • 139
  • 9
  • Thank you for you answer, however: bullets 1-2 do not explain why for a given computer the "animation" occurs for some MATLAB versions (i.e., 2018b, 2019b) and not in others (i.e. 2019a), as mentioned in the comments; bullet 3 seems to ignore that this effect was observed on both Windows and Linux systems, despite them having different interaction/event handling (not to mention that clicking or even hovering over a line is not required to observe the effect). Finally, will you please explain what the code is supposed to do (i.e., turn the "animation" off)? Did this work on your system? – Dev-iL Aug 04 '20 at 05:43
  • @Dev-iL The repaint event causes the "animation". To disable this behaviour, you could simply set the HitTest of gca/gcf to "off" status. – Shannon Aug 04 '20 at 09:07
  • `HitTest` is used for capturing mouse clicks, [as far as I can tell](https://www.mathworks.com/help/matlab/creating_plots/capturing-mouse-clicks.html), yet the animation effect doesn't require any mouse clicks. If so, what does `HitTest` have to do with repainting? Do you have access to a setup (OS+MATLAB) that exhibits this "animation" effect? If so - would you please mention your configuration? – Dev-iL Aug 04 '20 at 09:12
  • Enable HitTest Visibility means allow object selection throuth mouse click. There is a default selection event on Linux&Mac when you move over a figure. Lot's of events would fire the repainting event. You can get all the callback functions (end with "Fcn") using: get(gcf). You could take over the control by override these functions to prevent repainting. – Shannon Aug 05 '20 at 03:07
  • This has nothing to do with the `ButtonDownFcn` callback, but setting `HitTest` to off does stop the animation. – Cris Luengo Sep 15 '20 at 07:10