Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Speed of new graphics engine
611 views
Skip to first unread message
Rob Campbell
Nov 15, 2014, 4:42:14 AM11/15/14
to
> The plot toolbox is extremely slow when I trying to open a plot with about 1M data points.
Indeed. Unfortunately 2014b is unusable for me. The slow display coupled with the horribly bloated EPS files is a killer. TMW say they're working on this, if it's any help. However, since it's so obviously broken, I don't under understand how this stuff even made it to release.
Indeed. Unfortunately 2014b is unusable for me. The slow display coupled with the horribly bloated EPS files is a killer. TMW say they're working on this, if it's any help. However, since it's so obviously broken, I don't under understand how this stuff even made it to release.
dpb
Nov 15, 2014, 8:43:26 AM11/15/14
to
--
Ben
Nov 27, 2014, 10:08:17 AM11/27/14
to
"Emiel" wrote in message <m2nv3e$4na$1...@newscl01ah.mathworks.com>...
> Dear all,
>
> When I run the code "function test_hax" below, I get with
>
> R2014b, tic-toc-time: 10.0 sec; windows 7
>
> On a different computer with windows 8.1
> R2014b, tic-toc-time: 8.8 sec;
> R2014a, tic-toc-time: 0.4 sec;
Hello,
Behavior confirmed for your test:
Windows 7, software 'false', latest drivers installed.
R2014b : 8.8 sec
R2013a : 0.35 sec
For whatI usually do in Matlab, trying to plot several signals of length more than, say, 30,000 points each results in irritatingly slow plots. Plotting is slow, zooming in and resizing the window as well... Barely usable it is!
There's something so obviously wrong with this new graphics engine, that it's really a pity it has been released. TMW used to be more serious than this...
Ben
> Dear all,
>
> When I run the code "function test_hax" below, I get with
>
> R2014b, tic-toc-time: 10.0 sec; windows 7
>
> On a different computer with windows 8.1
> R2014b, tic-toc-time: 8.8 sec;
> R2014a, tic-toc-time: 0.4 sec;
Hello,
Behavior confirmed for your test:
Windows 7, software 'false', latest drivers installed.
R2014b : 8.8 sec
R2013a : 0.35 sec
For whatI usually do in Matlab, trying to plot several signals of length more than, say, 30,000 points each results in irritatingly slow plots. Plotting is slow, zooming in and resizing the window as well... Barely usable it is!
There's something so obviously wrong with this new graphics engine, that it's really a pity it has been released. TMW used to be more serious than this...
Ben
Chris
Jan 13, 2015, 12:59:12 PM1/13/15
to
Very informative thread.
I've done benchmarking and found that performance of 2014b vs much old - depends on the situation. My application is many subplots with scrolling subplots at high FPS. Eg an oscilloscope with many displays.
One very big improvement for me comes from turning off graphic smoothing. I
set(gcf, 'GraphicsSmoothing','off')
This almost makes 2014b faster in all cases even with hardware support:
opengl('info') reports
'GeForce 8600 GTS/PCIe/SSE2'
software = 'false'
Changing the renderer can also make a difference.
http://www.mathworks.com/help/matlab/ref/figure-properties.html
Overall figure window size (not area of the specific subplot) makes a bit difference.
I pasted a function to report FPS from 3 second runs.
x=0:0.001:100;
y=sin(x) + rand(size(x));
fun_exp_plot4(3, 1,1,1,x,y,5e4)
Chris
function [FPS] = plot_exp(run_time, num_plots, nx, ny, x, y, pts)
% function [FPS] = plot_exp(run_time, num_plots, nx, ny, x, y, pts)
% calculate the FPS for an oscilloscope display
%
% try with different figure sizes, number of plots, etc
%
% x=0:0.001:100;
% y=sin(x);
%or y=sin(x) + rand(size(x));
%
% examples:
% 1 plot, 3 seconds test, with 500 points
% fun_exp_plot4(3, 1,1,1, x,y, 5e2)
%
% 1 plot with 50,000 points
% fun_exp_plot4(3, 1,1,1, x,y, 5e4)
%
% 4 plots with 50k points
% fun_exp_plot4(3, 4,2,2, x,y, 5e4)
%
% some performance effects in 2014b
%
% set(gcf, 'GraphicsSmoothing','off')
% set(gcf, 'Renderer','painters')
% set(gcf, 'Renderer','opengl')
clf;
cla;
drawnow;
%set(gcf,'Position',[-1500 500 1400 500])
%set(gcf,'Position',[-1500 500 500 500])
idx = 0;
ndx=1:pts;
h=[];
for i = 1:num_plots
subplot(nx,ny,i)
% h(i) =plot(x(1),y(1),'.','markersize',1);
h(i) =plot(x(1),y(1) );
set(h(i),'xdata',x(ndx),'ydata',y(ndx+idx+1000*i));
end
idx = 0;
% set(gcf,'Visible','off');
a=tic();
while toc(a) < run_time
idx = idx + 1;
for i = 1:num_plots
set(h(i),'ydata',y(ndx+idx*20+1000*i));
end
drawnow expose % update will skip redrawing...
end;
dt=toc(a);
FPS = idx/dt;
I've done benchmarking and found that performance of 2014b vs much old - depends on the situation. My application is many subplots with scrolling subplots at high FPS. Eg an oscilloscope with many displays.
One very big improvement for me comes from turning off graphic smoothing. I
set(gcf, 'GraphicsSmoothing','off')
This almost makes 2014b faster in all cases even with hardware support:
opengl('info') reports
'GeForce 8600 GTS/PCIe/SSE2'
software = 'false'
Changing the renderer can also make a difference.
http://www.mathworks.com/help/matlab/ref/figure-properties.html
Overall figure window size (not area of the specific subplot) makes a bit difference.
I pasted a function to report FPS from 3 second runs.
x=0:0.001:100;
y=sin(x) + rand(size(x));
fun_exp_plot4(3, 1,1,1,x,y,5e4)
Chris
function [FPS] = plot_exp(run_time, num_plots, nx, ny, x, y, pts)
% function [FPS] = plot_exp(run_time, num_plots, nx, ny, x, y, pts)
% calculate the FPS for an oscilloscope display
%
% try with different figure sizes, number of plots, etc
%
% x=0:0.001:100;
% y=sin(x);
%or y=sin(x) + rand(size(x));
%
% examples:
% 1 plot, 3 seconds test, with 500 points
% fun_exp_plot4(3, 1,1,1, x,y, 5e2)
%
% 1 plot with 50,000 points
% fun_exp_plot4(3, 1,1,1, x,y, 5e4)
%
% 4 plots with 50k points
% fun_exp_plot4(3, 4,2,2, x,y, 5e4)
%
% some performance effects in 2014b
%
% set(gcf, 'GraphicsSmoothing','off')
% set(gcf, 'Renderer','painters')
% set(gcf, 'Renderer','opengl')
clf;
cla;
drawnow;
%set(gcf,'Position',[-1500 500 1400 500])
%set(gcf,'Position',[-1500 500 500 500])
idx = 0;
ndx=1:pts;
h=[];
for i = 1:num_plots
subplot(nx,ny,i)
% h(i) =plot(x(1),y(1),'.','markersize',1);
h(i) =plot(x(1),y(1) );
set(h(i),'xdata',x(ndx),'ydata',y(ndx+idx+1000*i));
end
idx = 0;
% set(gcf,'Visible','off');
a=tic();
while toc(a) < run_time
idx = idx + 1;
for i = 1:num_plots
set(h(i),'ydata',y(ndx+idx*20+1000*i));
end
drawnow expose % update will skip redrawing...
end;
dt=toc(a);
FPS = idx/dt;
Trey
Jan 14, 2015, 4:20:11 PM1/14/15
to
Thanks. I'm seeing a slowdown of 20x with 'inputsdlg' (a spiffy add-on to inputdlg from matlabcentral).
I tried
set(gcf, 'GraphicsSmoothing','off')
right before the 'drawnow'. Didn't work. But that spurred me to check the same help topic that describes 'GraphicsSmoothing'. Turns out
set(gcf, 'Renderer', 'painters')
works. It's now just as fast as 2014a. This turns off OpenGL rendering of course. I'm only doing this inside 'inputsdlg'.
Trey
"Chris" wrote in message <m93mda$9s1$1...@newscl01ah.mathworks.com>...
I tried
set(gcf, 'GraphicsSmoothing','off')
set(gcf, 'Renderer', 'painters')
Trey
"Chris" wrote in message <m93mda$9s1$1...@newscl01ah.mathworks.com>...
Paul Szabo
Feb 5, 2015, 6:45:25 PM2/5/15
to
With R2014a I see "opengl info" reporting
>> opengl info
Version = 2.1 Mesa 8.0.5
Vendor = VMware, Inc.
Renderer = Gallium 0.4 on llvmpipe (LLVM 0x209)
whereas with R2014b it reports:
>> opengl info
Version: '2.1 Mesa 7.2'
Vendor: 'Brian Paul'
Renderer: 'Mesa X11'
Is that a version regression? Any way to use the 8.0.5 libraries with R2014b?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
>> opengl info
Version = 2.1 Mesa 8.0.5
Vendor = VMware, Inc.
Renderer = Gallium 0.4 on llvmpipe (LLVM 0x209)
whereas with R2014b it reports:
>> opengl info
Version: '2.1 Mesa 7.2'
Vendor: 'Brian Paul'
Renderer: 'Mesa X11'
Is that a version regression? Any way to use the 8.0.5 libraries with R2014b?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
Pablo Iturralde
Feb 10, 2015, 9:28:13 AM2/10/15
to
I can confirm the same behavior (much slower graphics) on R2014b in Linux (Ubuntu 14.10). Also in the beta R2015a. Software opengl is set as 'false', using latest Nvidia drivers (331.113).
Besides slower graphics and bloated eps, I am unable to open some saved .figs created with the same Matlab version (Matlab keeps working at it for 15+ mins, never really stuck to see if the process eventually finishes). All the figures that cause problems are rather heavy plots, but that were working in R2014a.
Is there any update from TMW for a fix to this? I like the improvements on R2014b, but this makes it unusable on many typical work situations. Unfortunately I believe my University does not support licenses for older Matlab versions, so I'm forced to use the latest one.
"Paul Szabo" <p...@maths.usyd.edu.au> wrote in message <mb0vah$ao3$1...@newscl01ah.mathworks.com>...
Besides slower graphics and bloated eps, I am unable to open some saved .figs created with the same Matlab version (Matlab keeps working at it for 15+ mins, never really stuck to see if the process eventually finishes). All the figures that cause problems are rather heavy plots, but that were working in R2014a.
Is there any update from TMW for a fix to this? I like the improvements on R2014b, but this makes it unusable on many typical work situations. Unfortunately I believe my University does not support licenses for older Matlab versions, so I'm forced to use the latest one.
"Paul Szabo" <p...@maths.usyd.edu.au> wrote in message <mb0vah$ao3$1...@newscl01ah.mathworks.com>...
Pablo Iturralde
Feb 10, 2015, 9:39:11 AM2/10/15
to
I've tried some testing disabling the Nvidia card and using the Intel one. The problem is still there (3.0 Mesa 10.3.2, Software 'true').
"Pablo Iturralde" <pa...@pitt.edu> wrote in message <mbd4ho$23p$1...@newscl01ah.mathworks.com>...
"Pablo Iturralde" <pa...@pitt.edu> wrote in message <mbd4ho$23p$1...@newscl01ah.mathworks.com>...
Colin Paul de Gloucester
Feb 13, 2015, 12:12:06 PM2/13/15
to
On February 10th, 2015, Pablo Iturralde posted:
|--------------------------------------------------------------------------------|
|"[. . .] |
Ouch.
Yours sincerely,
Colin Paul de Gloucester
|--------------------------------------------------------------------------------|
|"[. . .] |
| |
|Unfortunately I believe my University does not support licenses for older Matlab|
|versions, so I'm forced to use the latest one." |
|--------------------------------------------------------------------------------|
|Unfortunately I believe my University does not support licenses for older Matlab|
|versions, so I'm forced to use the latest one." |
Ouch.
Yours sincerely,
Colin Paul de Gloucester
Chad Smith
Apr 28, 2015, 3:52:33 PM4/28/15
to
"Rob Campbell" wrote in message <m19dvv$r23$1...@newscl01ah.mathworks.com>...
> Hey people,
>
> I tried out 2014b today (Linux version), having high hopes for the new graphics engine. Quick initial impressions aren't great. Good thing: the plots look better on screen. Bad thing: it's deathly slowly for even moderately complicated line plots. 5 to 10 seconds for the window to re-draw following a resize, for instance. The older graphics engine was already not fast, so it's disappointing to see a big step back. I also saw a large increase in EPS file size, but haven't verified that yet.
>
> How are other people finding the new engine?
I can confirm this behavior on my Lenovo running Ubuntu 14.04.
When running a plotting script in 2014a, the process takes less than 1 min 20 seconds, and consumes about 4GB of RAM (7GB used by my system in total).
When running the exact same script with the exact same data in 2014b (and 2015b), the process exceeds my 11.5 GB of memory, and is killed by the kernel.
Output from dmesg:
[13859.007751] Out of memory: Kill process 18123 (MATLAB) score 658 or sacrifice child
[13859.007754] Killed process 18123 (MATLAB) total-vm:11218472kB, anon-rss:7876644kB, file-rss:0kB
I tried to get around the RAM issue, and created 100GB of swap on my computer. I then re-ran the script with 2014b, and about 90GB memory (!!!) is consumed by Matlab at which point I waited... for 30 minutes. And nothing happened.
I am now stuck using 2014a.
> Hey people,
>
> I tried out 2014b today (Linux version), having high hopes for the new graphics engine. Quick initial impressions aren't great. Good thing: the plots look better on screen. Bad thing: it's deathly slowly for even moderately complicated line plots. 5 to 10 seconds for the window to re-draw following a resize, for instance. The older graphics engine was already not fast, so it's disappointing to see a big step back. I also saw a large increase in EPS file size, but haven't verified that yet.
>
> How are other people finding the new engine?
I can confirm this behavior on my Lenovo running Ubuntu 14.04.
When running a plotting script in 2014a, the process takes less than 1 min 20 seconds, and consumes about 4GB of RAM (7GB used by my system in total).
When running the exact same script with the exact same data in 2014b (and 2015b), the process exceeds my 11.5 GB of memory, and is killed by the kernel.
Output from dmesg:
[13859.007751] Out of memory: Kill process 18123 (MATLAB) score 658 or sacrifice child
[13859.007754] Killed process 18123 (MATLAB) total-vm:11218472kB, anon-rss:7876644kB, file-rss:0kB
I tried to get around the RAM issue, and created 100GB of swap on my computer. I then re-ran the script with 2014b, and about 90GB memory (!!!) is consumed by Matlab at which point I waited... for 30 minutes. And nothing happened.
I am now stuck using 2014a.
Steven Lord
Apr 29, 2015, 10:18:23 AM4/29/15
to
"Chad Smith" <chad....@zee.aero> wrote in message
news:mhoods$6s4$1...@newscl01ah.mathworks.com...
1) Using each of the renderer options, OpenGL and painters.
f = figure('Renderer', 'opengl');
f = figure('Renderer', 'painters');
2) Try selecting software OpenGL by starting MATLAB with the -softwareopengl
flag.
http://www.mathworks.com/help/matlab/ref/matlablinux.html
3) Try changing your graphics driver.
If none of those work, please send your script to Technical Support so they
can investigate why MATLAB graphics are performing so slowly on your
machine.
--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com
Matthew
Apr 29, 2015, 7:38:38 PM4/29/15
to
@SteveLord As discussed many times previously in this thread changing your graphics driver will do nothing to ease the pain that is MATLAB R2014b+ Graphics engine.
> please send your script to Technical Support so they
> can investigate why MATLAB graphics are performing so slowly...
This statement is completely laughable. The Mathworks will only tell you the that cant find any developers right now and hide the fact that this bug exists. Sharing bugs only goes one way with those guys.
> @ChadSmith I am now stuck using 2014a.
Like so many of us.
> please send your script to Technical Support so they
This statement is completely laughable. The Mathworks will only tell you the that cant find any developers right now and hide the fact that this bug exists. Sharing bugs only goes one way with those guys.
> @ChadSmith I am now stuck using 2014a.
Like so many of us.
Pablo Iturralde
Apr 30, 2015, 6:23:42 PM4/30/15
to
I can confirm this bug still exists when using R2014b on Ubuntu 15.04, using both Intel drivers and nvidia-346. It may be (*may be*) slightly faster than on previous drivers, although nowhere near R2014a performance.
In response to some other post: I tried opengl and it doesn't help.
In response to some other post: I tried opengl and it doesn't help.
Chad Smith
Apr 30, 2015, 7:12:43 PM4/30/15
to
I filed a bug with Mathworks called "Graphics engine prohibitively memory intensive, slow", case number 01340690. They verified the bug, and the development team requested I send in my dataset and script, which I did this morning. Hopefully a fix is on the way.
Chad Smith
May 1, 2015, 3:23:47 PM5/1/15
to
The MathWorks support team got back to me. The fix was to simply remove markers from my plot. My plot command was
h = plot(x,y,'o-','MarkerSize',1);
and it is now
h = plot(x,y);
which works just fine in 2014b.
They also said the marker issue is being investigated.
h = plot(x,y,'o-','MarkerSize',1);
and it is now
h = plot(x,y);
which works just fine in 2014b.
They also said the marker issue is being investigated.
Ippei Kotera
May 8, 2015, 12:02:06 AM5/8/15
to
Regarding the HG2 slowness, can some of you run the following snippet on your environment for me?
nFrames = 50; depth = 2^8;
stack = uint8(rand(2048, 2048, nFrames) .* depth);
figure; h = image(stack(:, :, 1)); colormap(gray(depth));
t = tic;
for ii = 1:nFrames
set(h, 'CData', stack(:, :, ii)); drawnow;
end
disp(['FPS = ', num2str(nFrames/toc(t))]);
I have large number of images from sCMOS camera (2048 x 2048, uint8) which I need to display sequentially on a MATLAB GUI. I used to get >50 fps before R2014a, but with R2014b, it dropped to ~5 fps. I would like to know if it has something to do with my environment (Win8.1 64bit/i7 3.2GHz/GTX670/24GB RAM) or the update. I confirmed that all the drivers are up to date and software OpenGL is set to false.
Thanks in advance.
nFrames = 50; depth = 2^8;
stack = uint8(rand(2048, 2048, nFrames) .* depth);
figure; h = image(stack(:, :, 1)); colormap(gray(depth));
t = tic;
for ii = 1:nFrames
set(h, 'CData', stack(:, :, ii)); drawnow;
end
disp(['FPS = ', num2str(nFrames/toc(t))]);
I have large number of images from sCMOS camera (2048 x 2048, uint8) which I need to display sequentially on a MATLAB GUI. I used to get >50 fps before R2014a, but with R2014b, it dropped to ~5 fps. I would like to know if it has something to do with my environment (Win8.1 64bit/i7 3.2GHz/GTX670/24GB RAM) or the update. I confirmed that all the drivers are up to date and software OpenGL is set to false.
Thanks in advance.
Matthew
May 8, 2015, 1:22:06 AM5/8/15
to
@Ippei Kotera
R2015a> FPS = 6.5573
R2014a> FPS = 63.4846
Environment (Win7 64bit/i7 3.2GHz/NVS300/16GB RAM)
R2015a> FPS = 6.5573
R2014a> FPS = 63.4846
Environment (Win7 64bit/i7 3.2GHz/NVS300/16GB RAM)
Nasser M. Abbasi
May 8, 2015, 2:50:30 AM5/8/15
to
On 5/7/2015 11:02 PM, Ippei Kotera wrote:
> nFrames = 50; depth = 2^8;
> stack = uint8(rand(2048, 2048, nFrames) .* depth);
> figure; h = image(stack(:, :, 1)); colormap(gray(depth));
> t = tic;
> for ii = 1:nFrames
> set(h, 'CData', stack(:, :, ii)); drawnow;
> end
> disp(['FPS = ', num2str(nFrames/toc(t))]);
windows 7, 64 bits. Using 32 bit Matlab:
> nFrames = 50; depth = 2^8;
> stack = uint8(rand(2048, 2048, nFrames) .* depth);
> figure; h = image(stack(:, :, 1)); colormap(gray(depth));
> t = tic;
> for ii = 1:nFrames
> set(h, 'CData', stack(:, :, ii)); drawnow;
> end
> disp(['FPS = ', num2str(nFrames/toc(t))]);
215a 6.49
213a 67.11
212a 71.20
--Nasser
Nasser M. Abbasi
May 8, 2015, 3:10:39 AM5/8/15
to
>> opengl info
Version: '4.4.0'
Vendor: 'NVIDIA Corporation'
Renderer: 'GeForce GTX 650/PCIe/SSE2'
MaxTextureSize: 16384
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Har...'
Software: 'false'
SupportsGraphicsSmoothing: 1
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
Extensions: {296x1 cell}
MaxFrameBufferSize: 16384
Bruno Luong
May 8, 2015, 5:05:05 AM5/8/15
to
Same PC with Windows 7:
- 80 FPS on R2012A Win64
- 7 FPS on R2015A Win64
- 80 FPS on R2012A Win64
- 7 FPS on R2015A Win64
Steven Lord
May 8, 2015, 10:42:24 AM5/8/15
to
"Ippei Kotera" <iko...@gmail.com> wrote in message
news:mihcfo$qus$1...@newscl01ah.mathworks.com...
Changing "drawnow" to "drawnow limitrate" resulted in a much higher FPS.
http://www.mathworks.com/help/matlab/ref/drawnow.html
This syntax was introduced in release R2015a, as described in the first item
in the Graphics section of the release R2015a Release Notes for MATLAB.
http://www.mathworks.com/help/matlab/release-notes.html
Bruno Luong
May 8, 2015, 12:34:07 PM5/8/15
to
Interesting, so "drawnow limitrate" is actually faster than full blast drawnow in this example for R2015a? Something is terribly wrong.
Steven Lord
May 8, 2015, 1:33:56 PM5/8/15
to
"Bruno Luong" <b.l...@fogale.findmycountry> wrote in message
news:miiohq$eva$1...@newscl01ah.mathworks.com...
> Interesting, so "drawnow limitrate" is actually faster than full blast
> drawnow in this example for R2015a? Something is terribly wrong.
Take a minute or so and run these two blocks of code.
> drawnow in this example for R2015a? Something is terribly wrong.
t1 = tic;
for k = 1:30
pause(1);
end
fprintf('Elapsed time for pause every iteration: %f\n', toc(t1));
t2 = tic;
for k = 1:30
if mod(k, 5) == 0
pause(3);
end
end
fprintf('Elapsed time for longer pause every 5th iteration: %f\n', toc(t2));
The first code block pauses for a shorter period of time (does less work)
than the second code block, but the second code block pauses less frequently
(does that work less often) than the first block. The first block is like
DRAWNOW; the second is like DRAWNOW LIMITRATE. [Granted, the metaphor is
crude, but I think you see what I mean.]
http://www.mathworks.com/help/matlab/ref/drawnow.html
"drawnow limitrate limits the number of updates to 20 frames per second. If
it has been fewer than 50 milliseconds since the last update, or if the
graphics renderer is busy with the previous change, then drawnow discards
the new updates. Use this command if you are updating graphics objects in a
loop and do not need to see every update on the screen. Skipping updates can
create faster animations. Pending callbacks are processed, so you can
interact with figures during animations."
Also see this "Mike on MATLAB Graphics" blog posting:
http://blogs.mathworks.com/graphics/2015/03/16/how-the-tiger-got-its-stripes/
One drawback to "drawnow limitrate" that comes to my mind, and the reason
why you might not want to use it all the time, is "then drawnow discards the
new updates." In some situations, that's okay to do while in others (if
you're capturing a movie in high speed that you want to display at a slower
speed or even step through frame-by-frame) it may not be okay.
Bruno Luong
May 8, 2015, 2:03:07 PM5/8/15
to
I more or less guess that the new graphic engine waste A LOT of time to update its OO graphic handles.
This way of slow-down to speed up is typically work-around to somewhat limit the drawback of the new graphical system.
We are working on camera that is able to have a frame rate up to 120 FPS. No way we can switch to R2014B or later with such performance.
And before anyone as; yes, human can clearly see the difference of animation above 20 FPS.
Bruno
This way of slow-down to speed up is typically work-around to somewhat limit the drawback of the new graphical system.
We are working on camera that is able to have a frame rate up to 120 FPS. No way we can switch to R2014B or later with such performance.
And before anyone as; yes, human can clearly see the difference of animation above 20 FPS.
Bruno
Ippei Kotera
May 8, 2015, 4:28:06 PM5/8/15
to
@Matthew, @Nasser, @Bruno,
Thank you guys for testing it. The results indeed confirm it's an HG2 issue, and it seems that the difference is universally substantial.
@Steve,
> In release R2015a, running your exact code gave an FPS value around 5.
> Changing "drawnow" to "drawnow limitrate" resulted in a much higher FPS.
Thanks for your suggestion. The limitrate option indeed helps finish the loop faster, but to my eyes, I see the images updated only a few times during the loop. It appears that the real FPS is much lower than 20, but I can't think of a way to measure the real FPS here.
Besides, in situations like bellow, there is no drawnow to use limitrate option, as images are updated in a callback function.
function testImageUpdate
addlistener(hs, 'ContinuousValueChange', @updateImage);
function updateImage(s, ~)
set(h, 'CData', stack(:, :, round(s.Value * (nFrames-1) + 1)));
end
end
If you drag the slider left and right, you'll notice a big difference between HG1 and HG2. Can you suggest something to help make this example less choppy and laggy in HG2?
Thanks.
Thank you guys for testing it. The results indeed confirm it's an HG2 issue, and it seems that the difference is universally substantial.
@Steve,
> In release R2015a, running your exact code gave an FPS value around 5.
> Changing "drawnow" to "drawnow limitrate" resulted in a much higher FPS.
Besides, in situations like bellow, there is no drawnow to use limitrate option, as images are updated in a callback function.
function testImageUpdate
nFrames = 50; depth = 2^8;
stack = uint8(rand(2048, 2048, nFrames) .* depth);
figure; h = image(stack(:, :, 1)); colormap(gray(depth));
hs = uicontrol('style', 'slider', 'Position', [30 5 500 20]);
stack = uint8(rand(2048, 2048, nFrames) .* depth);
figure; h = image(stack(:, :, 1)); colormap(gray(depth));
addlistener(hs, 'ContinuousValueChange', @updateImage);
function updateImage(s, ~)
set(h, 'CData', stack(:, :, round(s.Value * (nFrames-1) + 1)));
end
end
If you drag the slider left and right, you'll notice a big difference between HG1 and HG2. Can you suggest something to help make this example less choppy and laggy in HG2?
Thanks.
Emiel
May 9, 2015, 6:58:09 AM5/9/15
to
Dear all,
Here is an other simple example of
the slowness of the new HG2 graphic engine.
Please, run the code 'testSpeed' below and give us
your time-readings with your Matlab-version.
Thanks.
Mine results on the same computer are:
% =======================================
Creating axes in Matlab-2014a: 0.14476
Creating text in Matlab-2014a: 0.09161
% =======================================
Creating axes in Matlab-2015a: 2.1895
Creating text in Matlab-2015a: 11.0135
% =======================================
So:
creating axes in R2015a is 15x slower than R2014a
creating text in R2015a is 120x (!) slower than R2014a
% ===================================================
function testSpeed
getVersion = version('-release');
% Get pixel-dimensions of the Monitor
screenSize = get(groot, 'screenSize'); % screenSize = get(0, 'screenSize');
% Set Figure-dimensions depending of Monitor-dimensions
hFig = figure('position', [screenSize(1) + 5 50 screenSize(3) - 10 screenSize(4) - 135]);
figSize = get(hFig, 'position');
% Set Panel-dimensions depending of Figure-dimensions
hPanel = uipanel( ...
'parent', hFig, ...
'units', 'pixels', ...
'position', [5 5 figSize(3) - 10 figSize(4) - 20], ...
'back', [1 1 1]);
panelSize = get(hPanel, 'position');
% Total of 40 rows and 10 koloms in the Panel
nRows = 40; nKols = 10;
% Set Height and Width of the 400 Axes depending of Panel-dimensions
heigth = (panelSize(4) - 2) / nRows;
width = (panelSize(3) - 2) / nKols;
% Pre-allocation of Axes- and Text-handles
hAxes = gobjects(nRows, nKols); % hAxes = zeros(nRows, nKols);
hText = gobjects(nRows, nKols); % hText = zeros(nRows, nKols);
colorAxes = [1 1 1] * 0.9; fontSize = heigth / 2;
% ========== Creating axes in the Panel ======================
tic
for iRow = 1:nRows
for iKol = 1:nKols
hAxes(iRow, iKol) = axes ( ...
'parent', hPanel, ...
'units', 'pixels', ...
'pos', [1 + (iKol - 1) * width, panelSize(4) - iRow * heigth, width, heigth], ...
'color', colorAxes, ...
'box', 'on', ...
'xcolor', 1 - colorAxes, ...
'ycolor', 1 - colorAxes, ...
'xtick', [], ...
'ytick', [], ...
'vis', 'on');
end % for iKol=1:nKols
end % for iRow = 1:nRows
t1 = toc;
disp (['Creating axes in Matlab-' getVersion ': ' num2str(t1)])
% =========== Creating text in the Axes ====================
tic
for iRow = 1:nRows
for iKol = 1:nKols
hText(iRow, iKol) = text ( ...
'parent', hAxes(iRow, iKol), ...
'units', 'pixels', ...
'pos', [9 fontSize], ...
'color', 'k', ...
'string', [' Graphics - ' getVersion], ...
'fontname', 'helvetica', ...
'fontsize', fontSize, ...
'vis', 'on', ...
'userdata', [iRow, iKol]);
end % for iKol=1:nKols
end % for iRow = 1:nRows
t2 = toc;
disp (['Creating text in Matlab-' getVersion ': ' num2str(t2)])
end % function testSpeed
% ===================================================
Here is an other simple example of
the slowness of the new HG2 graphic engine.
Please, run the code 'testSpeed' below and give us
your time-readings with your Matlab-version.
Thanks.
Mine results on the same computer are:
% =======================================
Creating axes in Matlab-2014a: 0.14476
Creating text in Matlab-2014a: 0.09161
% =======================================
Creating axes in Matlab-2015a: 2.1895
Creating text in Matlab-2015a: 11.0135
% =======================================
So:
creating axes in R2015a is 15x slower than R2014a
creating text in R2015a is 120x (!) slower than R2014a
% ===================================================
function testSpeed
getVersion = version('-release');
% Get pixel-dimensions of the Monitor
screenSize = get(groot, 'screenSize'); % screenSize = get(0, 'screenSize');
% Set Figure-dimensions depending of Monitor-dimensions
hFig = figure('position', [screenSize(1) + 5 50 screenSize(3) - 10 screenSize(4) - 135]);
figSize = get(hFig, 'position');
% Set Panel-dimensions depending of Figure-dimensions
hPanel = uipanel( ...
'parent', hFig, ...
'units', 'pixels', ...
'position', [5 5 figSize(3) - 10 figSize(4) - 20], ...
'back', [1 1 1]);
panelSize = get(hPanel, 'position');
% Total of 40 rows and 10 koloms in the Panel
nRows = 40; nKols = 10;
% Set Height and Width of the 400 Axes depending of Panel-dimensions
heigth = (panelSize(4) - 2) / nRows;
width = (panelSize(3) - 2) / nKols;
% Pre-allocation of Axes- and Text-handles
hAxes = gobjects(nRows, nKols); % hAxes = zeros(nRows, nKols);
hText = gobjects(nRows, nKols); % hText = zeros(nRows, nKols);
colorAxes = [1 1 1] * 0.9; fontSize = heigth / 2;
% ========== Creating axes in the Panel ======================
tic
for iRow = 1:nRows
for iKol = 1:nKols
hAxes(iRow, iKol) = axes ( ...
'parent', hPanel, ...
'units', 'pixels', ...
'pos', [1 + (iKol - 1) * width, panelSize(4) - iRow * heigth, width, heigth], ...
'color', colorAxes, ...
'box', 'on', ...
'xcolor', 1 - colorAxes, ...
'ycolor', 1 - colorAxes, ...
'xtick', [], ...
'ytick', [], ...
'vis', 'on');
end % for iKol=1:nKols
end % for iRow = 1:nRows
t1 = toc;
disp (['Creating axes in Matlab-' getVersion ': ' num2str(t1)])
% =========== Creating text in the Axes ====================
tic
for iRow = 1:nRows
for iKol = 1:nKols
hText(iRow, iKol) = text ( ...
'parent', hAxes(iRow, iKol), ...
'units', 'pixels', ...
'pos', [9 fontSize], ...
'color', 'k', ...
'string', [' Graphics - ' getVersion], ...
'fontname', 'helvetica', ...
'fontsize', fontSize, ...
'vis', 'on', ...
'userdata', [iRow, iKol]);
end % for iKol=1:nKols
end % for iRow = 1:nRows
t2 = toc;
disp (['Creating text in Matlab-' getVersion ': ' num2str(t2)])
end % function testSpeed
% ===================================================
Bruno Luong
May 12, 2015, 5:58:12 PM5/12/15
to
"Emiel" wrote in message <mikp7s$gun$1...@newscl01ah.mathworks.com>...
> Dear all,
> Here is an other simple example of
> the slowness of the new HG2 graphic engine.
>
> Please, run the code 'testSpeed' below and give us
> your time-readings with your Matlab-version.
What is the purpose of timing graphical object *creation*?
> Here is an other simple example of
> the slowness of the new HG2 graphic engine.
>
> Please, run the code 'testSpeed' below and give us
> your time-readings with your Matlab-version.
Emiel
May 15, 2015, 7:41:17 AM5/15/15
to
"Bruno Luong" <b.l...@fogale.findmycountry> wrote in message <mitt1c$al0$1...@newscl01ah.mathworks.com>...
Dear Bruno Luong,
Sorry not to be clear enough about "the purpose of timing graphical object *creation*".
With my script above "testSpeed", I was hoping, that many readers
(even maybe Steven Lord) should submit their tic-toc readings.
In this way, I thought to convince TMW that something is definitely
wrong with the graphic speed since R2014b, caused by the new graphics engine HG2.
So, I hope you have a better understanding of "the purpose of timing graphical object *creation*" now.
Clearly, you are not the only one wondering what my purpose was, because
nobody have shown their tic/toc timings.
Or maybe I am the only one suffering from the speed-defect of the graphics engine HG2.
Sorry not to be clear enough about "the purpose of timing graphical object *creation*".
With my script above "testSpeed", I was hoping, that many readers
(even maybe Steven Lord) should submit their tic-toc readings.
In this way, I thought to convince TMW that something is definitely
wrong with the graphic speed since R2014b, caused by the new graphics engine HG2.
So, I hope you have a better understanding of "the purpose of timing graphical object *creation*" now.
Clearly, you are not the only one wondering what my purpose was, because
nobody have shown their tic/toc timings.
Or maybe I am the only one suffering from the speed-defect of the graphics engine HG2.
Yair Altman
May 15, 2015, 9:05:17 AM5/15/15
to
"Emiel" wrote in message <mj4m0p$nqs$1...@newscl01ah.mathworks.com>...
[snip]
> With my script above "testSpeed", I was hoping, that many readers
> (even maybe Steven Lord) should submit their tic-toc readings.
> In this way, I thought to convince TMW that something is definitely
> wrong with the graphic speed since R2014b, caused by the new graphics engine HG2.
[...]
2) I already reported it on my website in 2013 (http://undocumentedmatlab.com/blog/hg2-update), before HG2 went public. It is unfortunate that HG2 was released when this fact was known, and also unfortunate that it is still not fixed.
3) I believe that MathWorks (MW) are indeed aware of this serious problem. With all the public outcry about HG2's performance, it would be impossible for them to ignore it. In fact, I'm pretty sure that this specific newsgroup thread is monitored by quite a few MathWorkers. But fixing the problem is not as easy as flipping a switch, so it might take another release or two (or more) until we see HG1's performance again.
4) I think MW could do a much better job at communication here, publicly admit this serious performance regression, and offer meaningful workarounds. You can find some practical advice in my "Accelerating MATLAB Performance" book (e.g., use plot lines without markers, or use a different figure renderer), and in MW's http://www.mathworks.com/help/matlab/graphics-performance.html page. But I would love to see a more prominent official MW doc page that lists practical ideas and is linked from the various plotting functions' doc pages for easy access. At the moment, the above webpage is almost hidden in the forest of information, and the performance information is not concentrated. I also expect MW to publicize an expected timeline for the problem's fix - this goes against MW's reluctance to disclose their roadmap, but such a major regression deserves out-of-the-ordinary management from MW
to help users overcome it, until the future release that will ultimately solve the issue. If this problem is expected to be fixed in 15b (or 16a or whenever), then it would help users to know that *TODAY*. So far I am sad to say that I have not seen any public actions from MW commensurate with the seriousness of the problem.
5) With all this being said, my understanding of MW's engineering corporate culture and the people involved, make me optimistic that MW are doing their utmost to fix this problem as fast as they can, in the best possible way. MW could probably do a better job with the communication/documentation side, but I am pretty certain that they are already doing the maximum on the engineering side, even if we don't hear anything public about this.
(p.s. - please don't kill the messenger...)
Yair Altman
http://UndocumentedMatlab.com
[snip]
> With my script above "testSpeed", I was hoping, that many readers
> (even maybe Steven Lord) should submit their tic-toc readings.
> In this way, I thought to convince TMW that something is definitely
> wrong with the graphic speed since R2014b, caused by the new graphics engine HG2.
> Or maybe I am the only one suffering from the speed-defect of the graphics engine HG2.
1) You are not the only one suffering from HG2's lousy performance. We all do. Many if not most Matlab users suffer from it. You don't need to convince anyone about it. I believe that HG2's performance is the biggest current technical problem with Matlab, by a wide margin.
2) I already reported it on my website in 2013 (http://undocumentedmatlab.com/blog/hg2-update), before HG2 went public. It is unfortunate that HG2 was released when this fact was known, and also unfortunate that it is still not fixed.
3) I believe that MathWorks (MW) are indeed aware of this serious problem. With all the public outcry about HG2's performance, it would be impossible for them to ignore it. In fact, I'm pretty sure that this specific newsgroup thread is monitored by quite a few MathWorkers. But fixing the problem is not as easy as flipping a switch, so it might take another release or two (or more) until we see HG1's performance again.
4) I think MW could do a much better job at communication here, publicly admit this serious performance regression, and offer meaningful workarounds. You can find some practical advice in my "Accelerating MATLAB Performance" book (e.g., use plot lines without markers, or use a different figure renderer), and in MW's http://www.mathworks.com/help/matlab/graphics-performance.html page. But I would love to see a more prominent official MW doc page that lists practical ideas and is linked from the various plotting functions' doc pages for easy access. At the moment, the above webpage is almost hidden in the forest of information, and the performance information is not concentrated. I also expect MW to publicize an expected timeline for the problem's fix - this goes against MW's reluctance to disclose their roadmap, but such a major regression deserves out-of-the-ordinary management from MW
to help users overcome it, until the future release that will ultimately solve the issue. If this problem is expected to be fixed in 15b (or 16a or whenever), then it would help users to know that *TODAY*. So far I am sad to say that I have not seen any public actions from MW commensurate with the seriousness of the problem.
5) With all this being said, my understanding of MW's engineering corporate culture and the people involved, make me optimistic that MW are doing their utmost to fix this problem as fast as they can, in the best possible way. MW could probably do a better job with the communication/documentation side, but I am pretty certain that they are already doing the maximum on the engineering side, even if we don't hear anything public about this.
(p.s. - please don't kill the messenger...)
Yair Altman
http://UndocumentedMatlab.com
Emiel
May 15, 2015, 10:24:17 AM5/15/15
to
"Yair Altman" <altma...@gmailDEL.comDEL> wrote in message <mj4qu8$6u1$1...@newscl01ah.mathworks.com>...
Dear Yair Altman,
> 3) I believe that MathWorks (MW) are indeed aware of this serious problem. ...
I doubt it.
Steven Lord recommended us in this thread:
- Using each of the renderer options, OpenGL and painters.
- Try selecting software OpenGL by starting MATLAB with the -softwareopengl
flag.
- Try changing YOUR graphics driver.
and
If none of those work, please send YOUR script to Technical Support so they
can investigate why MATLAB graphics are performing so slowly on YOUR
machine.
Steven also advised to use DRAWNOW LIMITRATE (in some cases) instead of DRAWNOW.
Nothing wrong with these advices to change/try things on OUR site,
but no word that there is any possibility of a poor performance of HG2.
> 4) ... If this problem is expected to be fixed in 15b (or 16a or whenever) ...
You are very optimistic.
I guess R2020b or later.
> 3) I believe that MathWorks (MW) are indeed aware of this serious problem. ...
I doubt it.
Steven Lord recommended us in this thread:
- Using each of the renderer options, OpenGL and painters.
- Try selecting software OpenGL by starting MATLAB with the -softwareopengl
flag.
- Try changing YOUR graphics driver.
and
If none of those work, please send YOUR script to Technical Support so they
can investigate why MATLAB graphics are performing so slowly on YOUR
machine.
Steven also advised to use DRAWNOW LIMITRATE (in some cases) instead of DRAWNOW.
Nothing wrong with these advices to change/try things on OUR site,
but no word that there is any possibility of a poor performance of HG2.
> 4) ... If this problem is expected to be fixed in 15b (or 16a or whenever) ...
You are very optimistic.
I guess R2020b or later.
Pablo Iturralde
May 15, 2015, 6:15:17 PM5/15/15
to
I agree, I don't think MW is aware of this or at the very least they are not acknowledging it. I did get some support folks contact me about the issues and suggesting I try the things others have talked about here, but at the end of the day there were no solutions (other than 'do not use markers').
Here's my results:
Creating axes in Matlab-2014a: 0.10606
Creating text in Matlab-2014a: 0.077211
Creating axes in Matlab-2014b: 2.1364
Creating text in Matlab-2014b: 16.499
Creating axes in Matlab-2015a: 5.4545
Creating text in Matlab-2015a: 11.0519
Creating axes in Matlab-2015a: 2.6172
Creating text in Matlab-2015a: 12.1785
Yes, I do have three Matlab versions (I cannot uninstall R2014a because of these issues, and I installed 2015a beta hoping for a solution). I run 2015a twice because it seems to be faster the second time around.
I am running Ubuntu 15.04 64 bits with nVidia 346 drivers (proprietary), but I first noticed the issue on 14.04 with nVidia 331. Disabling my nVidia GPU and using the Intel one (which imples using another driver set) changes NOTHING.
-Pablo
Here's my results:
Creating axes in Matlab-2014a: 0.10606
Creating text in Matlab-2014a: 0.077211
Creating axes in Matlab-2014b: 2.1364
Creating text in Matlab-2014b: 16.499
Creating axes in Matlab-2015a: 5.4545
Creating text in Matlab-2015a: 11.0519
Creating axes in Matlab-2015a: 2.6172
Creating text in Matlab-2015a: 12.1785
Yes, I do have three Matlab versions (I cannot uninstall R2014a because of these issues, and I installed 2015a beta hoping for a solution). I run 2015a twice because it seems to be faster the second time around.
I am running Ubuntu 15.04 64 bits with nVidia 346 drivers (proprietary), but I first noticed the issue on 14.04 with nVidia 331. Disabling my nVidia GPU and using the Intel one (which imples using another driver set) changes NOTHING.
-Pablo
Bruno Luong
May 16, 2015, 2:34:18 AM5/16/15
to
I have no doubt they must aware about this issue.
However I'm not sure if they take it with the right level of severity of the issue.
TMW developers should have some sort of speed specification, and nothing should be released if the graphic engine does not passed the test.
Also, without the spec, they will not admitted the issues from user's complains.
I have locked the upgrade and maintenance fee of our company on matlab license (excepted mine) because of the issue.
Bruno
However I'm not sure if they take it with the right level of severity of the issue.
TMW developers should have some sort of speed specification, and nothing should be released if the graphic engine does not passed the test.
Also, without the spec, they will not admitted the issues from user's complains.
I have locked the upgrade and maintenance fee of our company on matlab license (excepted mine) because of the issue.
Bruno
Bruno Luong
May 16, 2015, 2:41:19 AM5/16/15
to
"Emiel" wrote in message <mikp7s$gun$1...@newscl01ah.mathworks.com>...
> Dear all,
> Here is an other simple example of
> the slowness of the new HG2 graphic engine.
>
> Please, run the code 'testSpeed' below and give us
> your time-readings with your Matlab-version.
>
> Thanks.
I run 4 times on 2 ML versions, Win64 laptop
> Here is an other simple example of
> the slowness of the new HG2 graphic engine.
>
> Please, run the code 'testSpeed' below and give us
> your time-readings with your Matlab-version.
>
> Thanks.
HG1:
>> testSpeed
Creating axes in Matlab-2014a: 0.12113
Creating text in Matlab-2014a: 0.07408
>> testSpeed
Creating axes in Matlab-2014a: 0.12636
Creating text in Matlab-2014a: 0.071325
>> testSpeed
Creating axes in Matlab-2014a: 0.12394
Creating text in Matlab-2014a: 0.071467
>> testSpeed
Creating axes in Matlab-2014a: 0.12271
Creating text in Matlab-2014a: 0.072018
>>
HG2:
>> testSpeed
Creating axes in Matlab-2015a: 2.6736
Creating text in Matlab-2015a: 11.1157
>> testSpeed
Creating axes in Matlab-2015a: 2.0335
Creating text in Matlab-2015a: 9.0747
>> testSpeed
Creating axes in Matlab-2015a: 1.9659
Creating text in Matlab-2015a: 8.72
>> testSpeed
Creating axes in Matlab-2015a: 2.0429
Creating text in Matlab-2015a: 9.1795
>>
Emiel
May 16, 2015, 5:45:24 AM5/16/15
to
"Bruno Luong" <b.l...@fogale.findmycountry> wrote in message <mj6od6$8ni$1...@newscl01ah.mathworks.com>...
@ Pablo Iturralde
@ Bruno Luong
Thanks for your tic/toc times.
These readings are in the same range as mine.
Dear Bruno Luong
> TMW developers should have some sort of speed specification, and nothing should be released if the graphic engine does not passed
> the test.
Hmm.
What kind of sloppy speed specification should that be ?
e.g. The generation of a text object in an axes object is about
120x (no typo !) slower in R2015a (HG2) than in R2014a (HG1).!
> I have no doubt they must aware about this issue.
This mystery could easily be solved when somebody of the TMW
run the script above "testSpeed" (message 53 of this thread)
and reveal their tic/toc-timings here (come on Steve Lord, give it a try) .
Then we know at least, depending on their time-results:
1. that either something is wrong with OUR drivers, OUR machines,
OUR renderer options and/or OUR scripts or the speed performance
of THEIR graphical engine HG2 is rubbish.
2. and that TMW is aware of the speedy-mess of the HG2 engine,
which doesn't mean of course TMW will try to solve this issue;
I'm afraid they have other priorities.
@ Bruno Luong
Thanks for your tic/toc times.
These readings are in the same range as mine.
Dear Bruno Luong
> TMW developers should have some sort of speed specification, and nothing should be released if the graphic engine does not passed
> the test.
What kind of sloppy speed specification should that be ?
e.g. The generation of a text object in an axes object is about
120x (no typo !) slower in R2015a (HG2) than in R2014a (HG1).!
> I have no doubt they must aware about this issue.
run the script above "testSpeed" (message 53 of this thread)
and reveal their tic/toc-timings here (come on Steve Lord, give it a try) .
Then we know at least, depending on their time-results:
1. that either something is wrong with OUR drivers, OUR machines,
OUR renderer options and/or OUR scripts or the speed performance
of THEIR graphical engine HG2 is rubbish.
2. and that TMW is aware of the speedy-mess of the HG2 engine,
which doesn't mean of course TMW will try to solve this issue;
I'm afraid they have other priorities.
Matthew
May 17, 2015, 8:42:25 PM5/17/15
to
"Emiel" wrote in message <mikp7s$gun$1...@newscl01ah.mathworks.com>...
> Please, run the code 'testSpeed' below and give us
> your time-readings with your Matlab-version.
@Emiel sorry for the delay in providing numbers. At my count this is the third piece of code provided in this thread. So here we go again...
> your time-readings with your Matlab-version.
>> testSpeed
Creating axes in Matlab-2014a: 0.11011
Creating text in Matlab-2014a: 0.094021
Creating axes in Matlab-2014b: 2.714
Creating text in Matlab-2014b: 8.6122
Creating axes in Matlab-2015a: 1.8592
Creating text in Matlab-2015a: 9.2205
So HG2 is 15-30 x slower than HG1 for creating axes and HG2 is 90-100 x slower than HG1 for creating text. And, Yes, I do have an existing application that requires reasonable performance for creating these graphical objects. Thanks Mathworks.
Matthew
May 17, 2015, 9:13:26 PM5/17/15
to
@Yair Altman
> 1) [snip] You don't need to convince anyone about it.
You must have received a much less flippant response to your MW support request than I did (and seemingly many others).
> 3) I believe that MathWorks (MW) are indeed aware of this serious problem. With all the
> public outcry about HG2's performance, it would be impossible for them to ignore it.
I respectively disagree. This thread is almost the only place where this issue is being discussed. Does this thread equate to a "public outcry" (?)
> 4) I think MW could do a much better job at communication here, publicly admit this
> serious performance regression, and offer meaningful workarounds.
The only serious workaround is to stick with R2014a.
> I also expect MW to publicize an expected timeline for the problem's fix - this goes against > MW's reluctance to disclose their roadmap, but such a major regression deserves out-of-
> the-ordinary management from MW to help users overcome it, until the future release that
> will ultimately solve the issue.
> If this problem is expected to be fixed in 15b (or 16a or whenever), then it would help users
> to know that *TODAY*. So far I am sad to say that I have not seen any public actions from
> MW commensurate with the seriousness of the problem.
Exactly this. Wouldn't it be GREAT.
> (p.s. - please don't kill the messenger...)
I will try not too. I'll even forgive you for plugging your book.
> http://UndocumentedMatlab.com
As good as MATLAB gets :-)
> 1) [snip] You don't need to convince anyone about it.
You must have received a much less flippant response to your MW support request than I did (and seemingly many others).
> 3) I believe that MathWorks (MW) are indeed aware of this serious problem. With all the
> public outcry about HG2's performance, it would be impossible for them to ignore it.
> 4) I think MW could do a much better job at communication here, publicly admit this
> serious performance regression, and offer meaningful workarounds.
> I also expect MW to publicize an expected timeline for the problem's fix - this goes against > MW's reluctance to disclose their roadmap, but such a major regression deserves out-of-
> the-ordinary management from MW to help users overcome it, until the future release that
> will ultimately solve the issue.
> If this problem is expected to be fixed in 15b (or 16a or whenever), then it would help users
> to know that *TODAY*. So far I am sad to say that I have not seen any public actions from
> MW commensurate with the seriousness of the problem.
> (p.s. - please don't kill the messenger...)
> http://UndocumentedMatlab.com
As good as MATLAB gets :-)
Werner
Jun 26, 2015, 11:22:11 AM6/26/15
to
Hello all,
Sorry, I don't know how to add a note to a specific thread, so I try it this way now ;-)
it seems the R2015a-Beta at time has no improvement of the new graphics engine.
Using the earlier posted test I got nearly the same time values as for R2014b.
this shows on physical computers (Win7u) and on theor VMware-machines (Suse 12.x).
None of the work-arounds in the thread have significant impact on speed ...
For my users I can only stop upgrades/installations above R2014a which has the well known and expected speed of Matlab ...
cheers
werner
Sorry, I don't know how to add a note to a specific thread, so I try it this way now ;-)
it seems the R2015a-Beta at time has no improvement of the new graphics engine.
Using the earlier posted test I got nearly the same time values as for R2014b.
this shows on physical computers (Win7u) and on theor VMware-machines (Suse 12.x).
None of the work-arounds in the thread have significant impact on speed ...
For my users I can only stop upgrades/installations above R2014a which has the well known and expected speed of Matlab ...
cheers
werner
B Ham
Jul 13, 2015, 12:54:16 PM7/13/15
to
"Werner" <werner...@hzg.de> wrote in message <mmjqmr$kn7$1...@newscl01ah.mathworks.com>...
I'm testing 2015b and no improvements over 2015a or 2014b on my machine.
David
Jul 27, 2015, 9:58:19 AM7/27/15
to
Hi Folks,
My name is David Garrison. I am a MATLAB Product Manager here at MathWorks. I’d like to respond to this thread generally and give you some information about work that we are doing to address the performance issues that you’ve raised.
First, thank you for all for your comments. Your feedback is very important to us. We like to hear positive feedback, of course, but we also want to hear about problem areas. It helps us improve our products. Second, be assured that we are listening. You’ll notice that several MathWorks people have posted replies with some advice on how to deal with specific issues raised here. We will continue to monitor your feedback and provide specific replies as appropriate. Third, please continue to share your information with our Technical Support staff. Your issue may seem to be similar to someone else’s but there may be workarounds that they can recommend for individual cases. Our Technical Support team can escalate your issue to development to see if other workarounds may be available.
Having reviewed this thread, it appears that many of the issues fall into four broad categories:
• Marker performance
• Performance related to plotting large amounts of data (large number of points or lines)
• Size of EPS files
• Graphics drivers and OpenGL
We are aware of these issues. Our graphics team has projects underway to address each of these issues. You can expect to see some improvements in R2015b with further improvements in R2016a and beyond.
In the meantime, there are resources that may be helpful. First, there is a Graphics Performance section in our documentation that provides some advice on how to avoid common performance problems. Second, check out Mike Garrity’s blog on MATLAB Graphics. Mike is a senior member of our graphics team. His blog is full of interesting information on MATLAB graphics including specific posts on how to optimize graphics performance. Third, check out MATLAB Answers -- it is often a good source of information. Finally, please contact out Technical Support staff. Often they can provide advice on how to deal with issues associated with the new graphics system. If you have tried these resources and are not getting the help you need, please reach out to me directly.
Thanks,
David Garrison
Principal MATLAB Product Manager
MathWorks, Inc.
david.g...@mathworks.com
My name is David Garrison. I am a MATLAB Product Manager here at MathWorks. I’d like to respond to this thread generally and give you some information about work that we are doing to address the performance issues that you’ve raised.
First, thank you for all for your comments. Your feedback is very important to us. We like to hear positive feedback, of course, but we also want to hear about problem areas. It helps us improve our products. Second, be assured that we are listening. You’ll notice that several MathWorks people have posted replies with some advice on how to deal with specific issues raised here. We will continue to monitor your feedback and provide specific replies as appropriate. Third, please continue to share your information with our Technical Support staff. Your issue may seem to be similar to someone else’s but there may be workarounds that they can recommend for individual cases. Our Technical Support team can escalate your issue to development to see if other workarounds may be available.
Having reviewed this thread, it appears that many of the issues fall into four broad categories:
• Marker performance
• Performance related to plotting large amounts of data (large number of points or lines)
• Size of EPS files
• Graphics drivers and OpenGL
We are aware of these issues. Our graphics team has projects underway to address each of these issues. You can expect to see some improvements in R2015b with further improvements in R2016a and beyond.
In the meantime, there are resources that may be helpful. First, there is a Graphics Performance section in our documentation that provides some advice on how to avoid common performance problems. Second, check out Mike Garrity’s blog on MATLAB Graphics. Mike is a senior member of our graphics team. His blog is full of interesting information on MATLAB graphics including specific posts on how to optimize graphics performance. Third, check out MATLAB Answers -- it is often a good source of information. Finally, please contact out Technical Support staff. Often they can provide advice on how to deal with issues associated with the new graphics system. If you have tried these resources and are not getting the help you need, please reach out to me directly.
Thanks,
David Garrison
Principal MATLAB Product Manager
MathWorks, Inc.
david.g...@mathworks.com
Bruno Luong
Jul 27, 2015, 11:58:11 AM7/27/15
to
David,
If you read post #43 onwards http://www.mathworks.com/matlabcentral/newsreader/view_thread/337755 the issue is not falling into you four broad categories.
It's a simple image updating that is 8-10 times slower than 2014A.
What I'm interested to know is that is the slowness is a hard limitation of HG2 engine or not.
TMW is welcome to provide the solution to solve the slowness reported in post #43..
If TMW tackles only the four broad issues, I personally think the you don't tackle to root cause.
The issue is serious. I suspend the year maintenance of all Matlab licences but mine since R2014a. I would suggest TMW to propose in the next releases the mean for users to select HG1 or HG2 for the time beeing.
Regards
Bruno
If you read post #43 onwards http://www.mathworks.com/matlabcentral/newsreader/view_thread/337755 the issue is not falling into you four broad categories.
It's a simple image updating that is 8-10 times slower than 2014A.
What I'm interested to know is that is the slowness is a hard limitation of HG2 engine or not.
TMW is welcome to provide the solution to solve the slowness reported in post #43..
If TMW tackles only the four broad issues, I personally think the you don't tackle to root cause.
The issue is serious. I suspend the year maintenance of all Matlab licences but mine since R2014a. I would suggest TMW to propose in the next releases the mean for users to select HG1 or HG2 for the time beeing.
Regards
Bruno
Dmitry Kaplan
Sep 11, 2015, 8:45:10 PM9/11/15
to
The ginput() performance has definitely something to do with markers:
Case A: figure;plot(rand(10e6,2));[a,b]=ginput(1) %perfectly usable
Case B: figure;plot(rand(10e6,2),'.'); [a,b]=ginput(1) %completely unusable
(at least on my two machines -- Win7/16G, Nvidia, R2015b)
Take a wild guess which one I need to use :-)
No amount of mucking with opengl, property settings, renderers, visibilities, marker sizes etc. makes a bit of difference. Wasted a half of a day on this nonsense. Both examples work just fine in R2014a
Bonus Case C: figure;plot(rand(10e6,2),'s'); %Eats all 16G of my RAM then crashes
This is truly becoming a "jump-the-shark" issue for me. Been using matlab since compiling the fortran source on a VAX.
/dmitry/
Case A: figure;plot(rand(10e6,2));[a,b]=ginput(1) %perfectly usable
Case B: figure;plot(rand(10e6,2),'.'); [a,b]=ginput(1) %completely unusable
(at least on my two machines -- Win7/16G, Nvidia, R2015b)
Take a wild guess which one I need to use :-)
No amount of mucking with opengl, property settings, renderers, visibilities, marker sizes etc. makes a bit of difference. Wasted a half of a day on this nonsense. Both examples work just fine in R2014a
Bonus Case C: figure;plot(rand(10e6,2),'s'); %Eats all 16G of my RAM then crashes
This is truly becoming a "jump-the-shark" issue for me. Been using matlab since compiling the fortran source on a VAX.
/dmitry/
Werner
Dec 15, 2015, 1:36:58 PM12/15/15
to
Hello all,
I'm just doing tests with 2016a-Prerelease ...
>> opengl info
Version: '3.3.0'
Vendor: 'NVIDIA Corporation'
Renderer: 'GeForce 310/PCIe/SSE2'
RendererDriverVersion: '9.18.13.4144'
RendererDriverReleaseDate: '03-Feb-2015'
MaxTextureSize: 8192
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardwa…'
Software: 'false'
HardwareSupportLevel: 'full'
MaxFrameBufferSize: 8192
>> test_fps
FPS = 15.354
>> test_speed
Creating axes in Matlab-2016a: 2.3592
Creating text in Matlab-2016a: 12.4715
>>
And this is what I see with 2014a on the same Hardware ...
>> opengl info
Version = 3.3.0
Vendor = NVIDIA Corporation
Renderer = GeForce 310/PCIe/SSE2
MaxTextureSize = 8192
Visual = 07 (RGB 32 bits(08 08 08 00) zdepth 24, Hardware Accelerated, Opengl, Double Buffered, Window)
Software = false
# of Extensions = 249
Driver Bug Workarounds:
OpenGLBitmapZbufferBug = 0
OpenGLWobbleTesselatorBug = 0
OpenGLLineSmoothingBug = 0
OpenGLDockingBug = 0
OpenGLClippedImageBug = 1
OpenGLEraseModeBug = 1
>> test_fps
FPS = 51.8161
>>
>> test_speed
Creating axes in Matlab-2014a: 0.15126
Creating text in Matlab-2014a: 0.093442
..... something is slow like a snake with OpenGL
... time to switch back to the fast Graphics Engine last shipped with 2014a?
Creating axes in Matlab-2016a: 2.3592
Creating text in Matlab-2016a: 12.4715
Sniff - why did I but the licenses for next year? ...
Regards
Werner
I'm just doing tests with 2016a-Prerelease ...
>> opengl info
Version: '3.3.0'
Vendor: 'NVIDIA Corporation'
Renderer: 'GeForce 310/PCIe/SSE2'
RendererDriverVersion: '9.18.13.4144'
RendererDriverReleaseDate: '03-Feb-2015'
MaxTextureSize: 8192
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardwa…'
Software: 'false'
HardwareSupportLevel: 'full'
SupportsGraphicsSmoothing: 1
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
Extensions: {248x1 cell}
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
MaxFrameBufferSize: 8192
>> test_fps
FPS = 15.354
>> test_speed
Creating axes in Matlab-2016a: 2.3592
Creating text in Matlab-2016a: 12.4715
>>
And this is what I see with 2014a on the same Hardware ...
>> opengl info
Version = 3.3.0
Vendor = NVIDIA Corporation
Renderer = GeForce 310/PCIe/SSE2
MaxTextureSize = 8192
Visual = 07 (RGB 32 bits(08 08 08 00) zdepth 24, Hardware Accelerated, Opengl, Double Buffered, Window)
Software = false
# of Extensions = 249
Driver Bug Workarounds:
OpenGLBitmapZbufferBug = 0
OpenGLWobbleTesselatorBug = 0
OpenGLLineSmoothingBug = 0
OpenGLDockingBug = 0
OpenGLClippedImageBug = 1
OpenGLEraseModeBug = 1
>> test_fps
FPS = 51.8161
>>
>> test_speed
Creating axes in Matlab-2014a: 0.15126
Creating text in Matlab-2014a: 0.093442
..... something is slow like a snake with OpenGL
... time to switch back to the fast Graphics Engine last shipped with 2014a?
Creating axes in Matlab-2016a: 2.3592
Creating text in Matlab-2016a: 12.4715
Sniff - why did I but the licenses for next year? ...
Regards
Werner
timo
Dec 15, 2015, 1:47:56 PM12/15/15
to
"Werner" <werner...@hzg.de> wrote in message <n4n4bv$4fm$1...@newscl01ah.mathworks.com>...
OMG that is depressing. I am cancelling my subscription. Thanx for the heads up.
Paramonte
Mar 9, 2016, 7:10:12 PM3/9/16
to
Have theses issues been corrected in R2016a? or even in R2015b?
Many thanks
Many thanks
Matthew
Mar 9, 2016, 9:41:11 PM3/9/16
to
"Paramonte" wrote in message <nbqe0r$i7d$1...@newscl01ah.mathworks.com>...
> Have theses issues been corrected in R2016a? or even in R2015b?
Hahahaha. That has to be a joke right (?) The Mathworks fix a serious set of bugs in 12-18 months. Funny :-(
Bruno Luong
Mar 10, 2016, 1:51:07 AM3/10/16
to
"Paramonte" wrote in message <nbqe0r$i7d$1...@newscl01ah.mathworks.com>...
> Have theses issues been corrected in R2016a? or even in R2015b?
>
> Many thanks
There is some improvement on plotting markers on 2016a.
>
> Many thanks
Other than that, I benchmark my application everytime a new version is coming, the performance of 2016a is still pathetic.
Paramonte
Mar 10, 2016, 5:16:09 AM3/10/16
to
"Bruno Luong" <b.l...@fogale.findmycountry> wrote in message <nbr5gn$8rj$1...@newscl01ah.mathworks.com>...
Compared to r2014a???? (the last version with the older graphic engine)
Bruno Luong
Mar 10, 2016, 7:33:09 AM3/10/16
to
"Paramonte" wrote in message <nbrhh3$4q8$1...@newscl01ah.mathworks.com>...
Of course, we are talking about HG2 speed in this thread.
Paramonte
Mar 10, 2016, 8:26:11 AM3/10/16
to
So what has been the general user´s trend: use r2014a and wait, or use the later versions and struggle with performance issues?
timo
Mar 10, 2016, 2:41:13 PM3/10/16
to
"Paramonte" wrote in message <nbrslb$rin$1...@newscl01ah.mathworks.com>...
Vendor: 'NVIDIA Corporation'
Renderer: 'GeForce GTX 770M/PCIe/SSE2'
RendererDriverVersion: '10.18.13.5891'
RendererDriverReleaseDate: '05-Nov-2015'
MaxTextureSize: 16384
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buffer,…'
MaxFrameBufferSize: 16384
>> testSpeed
Creating axes in Matlab-2016a: 2.2631
Creating text in Matlab-2016a: 8.6956
> So what has been the general user´s trend: use r2014a and wait, or use the later versions and struggle with performance issues?
Version: '4.5.0 NVIDIA 358.91'
Vendor: 'NVIDIA Corporation'
Renderer: 'GeForce GTX 770M/PCIe/SSE2'
RendererDriverVersion: '10.18.13.5891'
RendererDriverReleaseDate: '05-Nov-2015'
MaxTextureSize: 16384
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buffer,…'
Software: 'false'
HardwareSupportLevel: 'full'
SupportsGraphicsSmoothing: 1
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
Extensions: {322x1 cell}
HardwareSupportLevel: 'full'
SupportsGraphicsSmoothing: 1
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
MaxFrameBufferSize: 16384
>> testSpeed
Creating axes in Matlab-2016a: 2.2631
Creating text in Matlab-2016a: 8.6956
Paramonte
Mar 10, 2016, 4:18:10 PM3/10/16
to
>> testSpeed
Version = 3.3.11653 Compatibility Profile Context
Vendor = ATI Technologies Inc.
Renderer = ATI Radeon HD 4800 Series
MaxTextureSize = 8192
Visual = 02 (RGB 32 bits(08 08 08 08) zdepth 24, Hardware Accelerated, Opengl, Double Buffered, Window)
Software = false
# of Extensions = 196
Driver Bug Workarounds:
OpenGLBitmapZbufferBug = 0
OpenGLWobbleTesselatorBug = 0
OpenGLLineSmoothingBug = 0
OpenGLDockingBug = 0
OpenGLClippedImageBug = 0
OpenGLEraseModeBug = 0
Creating axes in Matlab-2014a: 0.28683
Creating text in Matlab-2014a: 0.17632
>> test_hax
Elapsed time is 0.777621 seconds.
>>
Version = 3.3.11653 Compatibility Profile Context
Vendor = ATI Technologies Inc.
Renderer = ATI Radeon HD 4800 Series
MaxTextureSize = 8192
Visual = 02 (RGB 32 bits(08 08 08 08) zdepth 24, Hardware Accelerated, Opengl, Double Buffered, Window)
Software = false
# of Extensions = 196
Driver Bug Workarounds:
OpenGLBitmapZbufferBug = 0
OpenGLWobbleTesselatorBug = 0
OpenGLLineSmoothingBug = 0
OpenGLDockingBug = 0
OpenGLEraseModeBug = 0
Creating axes in Matlab-2014a: 0.28683
Creating text in Matlab-2014a: 0.17632
>> test_hax
Elapsed time is 0.777621 seconds.
>>
Greg
Jun 30, 2016, 12:11:09 PM6/30/16
to
"Paramonte" wrote in message <nbrslb$rin$1...@newscl01ah.mathworks.com>...
> So what has been the general user´s trend: use r2014a and wait, or use the later versions and struggle with performance issues?
I have just been sticking with an older version. I have a script generating a number of plots with a lot of data that takes ~3 hours in 2012a in 2015a it doesn't even save the first figure after 3 weeks.
Has anyone else had problems saving figures with the new graphics engine?
Steven Lord
Jul 1, 2016, 9:02:13 AM7/1/16
to
"Greg" <har0...@byui.edu> wrote in message
news:nl3gan$g51$1...@newscl01ah.mathworks.com...
so they and the developers can determine the cause of this extreme slowdown.
--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com
Paramonte
Sep 30, 2016, 8:53:09 AM9/30/16
to
Has the speed of the graphic engine improved in the 2016a version?
Emiel
Sep 30, 2016, 10:45:08 AM9/30/16
to
"Paramonte" wrote in message <nsln7f$3s4$1...@newscl01ah.mathworks.com>...
and for those interested,
the speedresults (tic/toc) of the new release R2016b
by running "speedTest" (see #53 of this thread) are:
% =======================================
Creating axes in Matlab-2016b: 2.8519
Creating text in Matlab-2016b: 1.4246
% =======================================
Therefore,
the bad news is creating axes in R2016b is even slower (30%) than in R2015a/R2016a
the good news is creating text in R2016b is much faster (7.7x) than in R2015a/R2016a
Comparing these results of R2016b with those of the very old-fashioned
graphics system HG1 of R2014a (Those Were The Days, My Friend),
we get :
creating axes in R2016b is nearly 20x slower than in R2014a
creating text in R2016b is nearly 16x slower than in R2014a
Conclusion:
For creating axes- and/or text-objects R2016b is not a ground-breaking release.
> Has the speed of the graphic engine improved in the 2016a version?
Dear Paramonte
and for those interested,
the speedresults (tic/toc) of the new release R2016b
by running "speedTest" (see #53 of this thread) are:
% =======================================
Creating axes in Matlab-2016b: 2.8519
Creating text in Matlab-2016b: 1.4246
% =======================================
Therefore,
the bad news is creating axes in R2016b is even slower (30%) than in R2015a/R2016a
the good news is creating text in R2016b is much faster (7.7x) than in R2015a/R2016a
Comparing these results of R2016b with those of the very old-fashioned
graphics system HG1 of R2014a (Those Were The Days, My Friend),
we get :
creating axes in R2016b is nearly 20x slower than in R2014a
creating text in R2016b is nearly 16x slower than in R2014a
Conclusion:
For creating axes- and/or text-objects R2016b is not a ground-breaking release.
Bruno Luong
Sep 30, 2016, 10:54:07 AM9/30/16
to
TMW claims they improves speed for graphics with markers in V2016b.
I haven't tested yet.
I haven't tested yet.
Paramonte
Sep 30, 2016, 1:30:08 PM9/30/16
to
Dear Emiel
Those results are bad news for matlab users.
My question is how are the users dealing with the slow down in the graphics engine that ocurred after 2014a?
Are they sticking to that version (2014a) or earlier and waiting to see what the future brings?
Is this speed slow down not affecting their applications that much? Granted it will depend of the code load and data size, and it would be very nice to have inputs of users that could share with us their experiences when they migrated their code for matlab platforms posterior to 2104a. Anyone?
Big data matlab coders what is your experience?
Other thing is the silence treatment that mathworks is giving to the the concerned matlab users: Their remarks do not go further then: That should not be so, please contact Technical Support.
Please TMW give some feedback on this issue!!
Those results are bad news for matlab users.
My question is how are the users dealing with the slow down in the graphics engine that ocurred after 2014a?
Are they sticking to that version (2014a) or earlier and waiting to see what the future brings?
Is this speed slow down not affecting their applications that much? Granted it will depend of the code load and data size, and it would be very nice to have inputs of users that could share with us their experiences when they migrated their code for matlab platforms posterior to 2104a. Anyone?
Big data matlab coders what is your experience?
Other thing is the silence treatment that mathworks is giving to the the concerned matlab users: Their remarks do not go further then: That should not be so, please contact Technical Support.
Please TMW give some feedback on this issue!!
Bruno Luong
Sep 30, 2016, 2:18:08 PM9/30/16
to
"Paramonte" wrote in message <nsm7er$8hn$1...@newscl01ah.mathworks.com>...
I have app that plots few billions points, but I don't care much about speed, it can refresh at 5 Hz. The new graphic engine can handle it.
There are also some nice feature about animation in the recent MATLAB. But the coding is harder and it will not meet backward compatibility, and less universal accepted by someone else, if that is important for you.
I have another app that manipulates smaller data (image of 256Mpixels) and but want it to refresh at 50 Hz. I need to stay with V2014A to achieve that.
You just need to decide on your own.
> Dear Emiel
>
> Those results are bad news for matlab users.
>
> My question is how are the users dealing with the slow down in the graphics engine that ocurred after 2014a?
>
> Are they sticking to that version (2014a) or earlier and waiting to see what the future brings?
>
> Is this speed slow down not affecting their applications that much? Granted it will depend of the code load and data size, and it would be very nice to have inputs of users that could share with us their experiences when they migrated their code for matlab platforms posterior to 2104a. Anyone?
>
> Big data matlab coders what is your experience?
It's all depend on how big your data, and how fast you want it runs.
>
> Those results are bad news for matlab users.
>
> My question is how are the users dealing with the slow down in the graphics engine that ocurred after 2014a?
>
> Are they sticking to that version (2014a) or earlier and waiting to see what the future brings?
>
> Is this speed slow down not affecting their applications that much? Granted it will depend of the code load and data size, and it would be very nice to have inputs of users that could share with us their experiences when they migrated their code for matlab platforms posterior to 2104a. Anyone?
>
> Big data matlab coders what is your experience?
I have app that plots few billions points, but I don't care much about speed, it can refresh at 5 Hz. The new graphic engine can handle it.
There are also some nice feature about animation in the recent MATLAB. But the coding is harder and it will not meet backward compatibility, and less universal accepted by someone else, if that is important for you.
I have another app that manipulates smaller data (image of 256Mpixels) and but want it to refresh at 50 Hz. I need to stay with V2014A to achieve that.
You just need to decide on your own.
Daniel Frisch
Oct 2, 2016, 5:44:08 AM10/2/16
to
To improve performance, you can always reduce the number of data points that reside in the chart line handle's X/YData. The largest screen width these days is 4K, so you can produce a plot that looks exactly the same with just 8000 pixels, and skip the others. The function reduce_plot() can do that for you; it also handles interactions like zoom and pan.
To make zooming and scrolling even more convenient than Matlab figure's "interative modes", I submitted the function plotECG() where you can use sliders to browse through your signal – as in any audio mastering software, for example. It can handle millions of samples with good performance. plotECG() doesn't make use of object orientation, so it can be shipped as single file or even be pasted into your existing files as local function.
https://de.mathworks.com/matlabcentral/fileexchange/59296
To make zooming and scrolling even more convenient than Matlab figure's "interative modes", I submitted the function plotECG() where you can use sliders to browse through your signal – as in any audio mastering software, for example. It can handle millions of samples with good performance. plotECG() doesn't make use of object orientation, so it can be shipped as single file or even be pasted into your existing files as local function.
https://de.mathworks.com/matlabcentral/fileexchange/59296
Matt Raum
Nov 6, 2016, 8:15:08 AM11/6/16
to
Paramonte,
I don't consider the data that I plot to be very big, however, this problem still affects me. I develop a lot of interactive figures based on handle graphics callbacks and dynamic modification of plot data ('xdata','ydata','zdata').
While I have not done extensive testing, I worked enough with R2015a to discover that interfaces that were very powerful for exploring data under the old handle graphics library were much less functional using the new handle graphics library due to the increased latency in figure updates.
Since then I've been sticking with a pre 2014b releases and monitoring this thread in the hopes that there will be some progress on the speed of the handle graphics library in future releases. My main takeaway so far is that not much has changed since R2014b.
I remain hopeful that the update speed issues with HG2 can be addressed. I know I'll eventually have to upgrade to a post 2014a version of Matlab and I'd like to be able to keep using the tools that I've spent so much effort developing.
I don't consider the data that I plot to be very big, however, this problem still affects me. I develop a lot of interactive figures based on handle graphics callbacks and dynamic modification of plot data ('xdata','ydata','zdata').
While I have not done extensive testing, I worked enough with R2015a to discover that interfaces that were very powerful for exploring data under the old handle graphics library were much less functional using the new handle graphics library due to the increased latency in figure updates.
Since then I've been sticking with a pre 2014b releases and monitoring this thread in the hopes that there will be some progress on the speed of the handle graphics library in future releases. My main takeaway so far is that not much has changed since R2014b.
I remain hopeful that the update speed issues with HG2 can be addressed. I know I'll eventually have to upgrade to a post 2014a version of Matlab and I'd like to be able to keep using the tools that I've spent so much effort developing.
Nasser M. Abbasi
Nov 6, 2016, 11:46:20 AM11/6/16
to
On 11/6/2016 7:15 AM, Matt Raum wrote:
>
> While I have not done extensive testing, I worked enough with R2015a
>to discover that interfaces that were very powerful for exploring data
>under the old handle graphics library were much less functional
>using the new handle graphics library due to the increased latency in figure updates.
>
Any one has an idea at least what the cause of this
>
> While I have not done extensive testing, I worked enough with R2015a
>to discover that interfaces that were very powerful for exploring data
>under the old handle graphics library were much less functional
>using the new handle graphics library due to the increased latency in figure updates.
>
"increased latency in figure updates" is caused by in the new graphics?
I mean, which new aspect of the new graphics is causing this slow down?
Thanks,
--Nasser
Bruno Luong
Nov 6, 2016, 12:03:08 PM11/6/16
to
"Nasser M. Abbasi" wrote in message <nvnmom$1tea$1...@gioia.aioe.org>...
My guess is that the handles are now objects (and not numbers) imply much more complicated internal bookkeeping. There is no such thing as a free lunch.
> On 11/6/2016 7:15 AM, Matt Raum wrote:
>
> I mean, which new aspect of the new graphics is causing this slow down?
>
Only TMW people know, and they don't admit there is problem. But look at a number of users who prefer to stay with 2014a tells a different story.
>
> I mean, which new aspect of the new graphics is causing this slow down?
>
My guess is that the handles are now objects (and not numbers) imply much more complicated internal bookkeeping. There is no such thing as a free lunch.
Paramonte
Nov 9, 2016, 10:15:11 AM11/9/16
to
"Bruno Luong" wrote in message <
> My guess is that the handles are now objects (and not numbers) imply much more complicated internal bookkeeping. There is no such thing as a free lunch.
Humm TMW should come out and give some insight about this...
Paul Mennen
Nov 15, 2016, 2:22:08 AM11/15/16
to
Now that I have access to a computer with multiple versions of Matlab installed I thought I would run my own tests of graphics speed. My first test mostly measured the speed at which line objects can be updated. The program I used is called pltsq.m which is in the demo folder of my "plt" file exchange submission. This is a simple function which draws a plot with 5 lines each consisting of 101 points. The Ydata of each line is updated continuously in a small loop consisting of just a few lines of code. The amplitude of the trace values is slowly varied giving the appearance of a moving trace. There are no programmed delays, so the update rate (which is computed and displayed) gives a good measure of graphics speed. To replicate my results, just run pltsq.m, expand the figure to full screen and hit the start button.
The 3 versions of Matlab I had was R2015a (with the new graphics engine), R2009b, and R12.1 (also known as matlab version 6.1 which was released in 2001). I also compared the performance with a compiled version of pltsq.m which was created using the R12.1 matlab compiler along with the venerable (and free) Borland 5.5 C++ compiler (listed as BCC55 below).
R2015a: 18 updates/sec
R2009b: 438 updates/sec
R12.1: 781 updates/sec
BCC55: 863 updates/sec
Based on the complaints, I was expecting 2015a to be somewhat slow, but I was so shocked to see these results that I figure I must be testing incorrectly. But I'm not sure what. Does the new graphics engine require more potent graphics hardware to run properly ... perhaps a recent NVidia card or similar? These measurements were done with an Intel I7 processor with the Z68 Express chipset with the H67 HD Graphics Engine (all running under Windows 10). I did verify that the graphics drivers were up to date.
All four scenarios above animate smoothly, but with the 2015a version the amplitude changes at a glacial pace compared with the other 3 scenarios. I see that R2015a has a new graphics object called an "animated line". I only did a little experimentation with it but it didn't seem like it was going to get anywhere near the performance of the older versions. Also this begs the question ... why would we want fast lines and slow lines? Shouldn't they all be fast? Also what features of the line object do we have to give up to get fast lines (if indeed they are fast)?
Rather than just focusing on lines as I've done above I decided to also measure the time it takes for matlab to creating a large variety of graphical objects. For this test I replaced the matlab startup file with the following code:
----------------------------------------------------------------------------
function startup
plt5; bounce; circles12; curves; dice; editz; close('all');
gauss; gui1v6; gui2v6; movbar; plt50; pltmap; close('all');
pltn; pltquiv; pltsq; pltvbar; pub; pub2; close('all');
pub3; subplt; subplt8; subplt16; subplt20; tasplt; close('all');
trigplt; weight; wfall; wfalltst; winplt; close('all');
exit;
----------------------------------------------------------------------------
This function simply starts every example program included in the demo folder of my plt file exchange submission. This startup function (in total) creates and then deletes the following graphic objects:
35 figure windows
2384 line objects
970 uicontrols
893 text objects
273 axes
195 uicontext menus
13 uimenu objects
4 patch objects
2 image objects
Then I timed the whole mess by running batch files such as this, (the difference between the start & end times are reported below):
--------------------------------------------------
@ECHO OFF
ECHO Start time = %Time%
start /b /wait F:\Matlab2015a\bin\matlab.exe -wait
ECHO End time = %Time%
--------------------------------------------------
I noticed that the batch file would run faster the 2nd time, probably because Matlab starts much faster once the disk cache has been loaded. So to average out this effect and other random variations, I ran it 3 times and reported the average batch file execution time:
R2015a: 45.99 sec
R2009b: 24.84 sec
R12.1: 10.25 sec
BCC55: 7.09 sec
I had to make minor changes to the startup.m function to get it to compile, but the differences were not material and didn't change the number or type of graphics objects that were created. Lest you think this must be a measurement error, I can tell you that the difference is obvious even without any numbers. The figures fly up onto the screen in the older version so fast that there would not even be a hope of counting the figures as they appear. Not so with R2015a. Also I have carefully checked each of the 35 figure windows to make sure they look and behave the same in all four of the above scenarios. I would have also compared with a version compiled with the R2015a compiler if I had it, although I have been told that it wouldn't be any faster than R2015a itself.
My apologies to TMW if I've maligned their latest version by not using the appropriate hardware, but still one has to admire the Mathwork's programmers of two decades ago. They must have known a thing or two about writing efficient code even for modest hardware.
Perhaps all this talk about speed is misguided in the end. I have to admit that for the many matlab projects I have worked on over the last couple of decades, execution speed was not really an issue perhaps 99% of the time. It's usually been more about rapid development. On the other hand, I find it more fun to work with efficient, snappy software. It would be one thing if the new versions represented some kind of paradigm shift enabling more rapid development, but I haven't seen evidence of this. In fact I haven't found anything I can do easily in R2015a that I can't do just as quickly in R12.1.
By the way if anyone wants the BCC55 compiled version of the startup file so you can do your own comparisons I would be happy to share it with you. It's only a 4.9 Mbyte zip file which includes the executable and all required DLLs. (Matlab doesn't have to be on the machine). If you think I meant to type Gbyte ... no - it really is that small :) It only runs on a windows machine however (winXP thru Win10) as I don't know how to compile for a Linux machine. One of the 35 figure windows created in this compiled version is the pltsq figure used in line animation speed test that I discussed above, so you can also use this for your own line animation comparisons.
The 3 versions of Matlab I had was R2015a (with the new graphics engine), R2009b, and R12.1 (also known as matlab version 6.1 which was released in 2001). I also compared the performance with a compiled version of pltsq.m which was created using the R12.1 matlab compiler along with the venerable (and free) Borland 5.5 C++ compiler (listed as BCC55 below).
R2015a: 18 updates/sec
R2009b: 438 updates/sec
R12.1: 781 updates/sec
BCC55: 863 updates/sec
Based on the complaints, I was expecting 2015a to be somewhat slow, but I was so shocked to see these results that I figure I must be testing incorrectly. But I'm not sure what. Does the new graphics engine require more potent graphics hardware to run properly ... perhaps a recent NVidia card or similar? These measurements were done with an Intel I7 processor with the Z68 Express chipset with the H67 HD Graphics Engine (all running under Windows 10). I did verify that the graphics drivers were up to date.
All four scenarios above animate smoothly, but with the 2015a version the amplitude changes at a glacial pace compared with the other 3 scenarios. I see that R2015a has a new graphics object called an "animated line". I only did a little experimentation with it but it didn't seem like it was going to get anywhere near the performance of the older versions. Also this begs the question ... why would we want fast lines and slow lines? Shouldn't they all be fast? Also what features of the line object do we have to give up to get fast lines (if indeed they are fast)?
Rather than just focusing on lines as I've done above I decided to also measure the time it takes for matlab to creating a large variety of graphical objects. For this test I replaced the matlab startup file with the following code:
----------------------------------------------------------------------------
function startup
plt5; bounce; circles12; curves; dice; editz; close('all');
gauss; gui1v6; gui2v6; movbar; plt50; pltmap; close('all');
pltn; pltquiv; pltsq; pltvbar; pub; pub2; close('all');
pub3; subplt; subplt8; subplt16; subplt20; tasplt; close('all');
trigplt; weight; wfall; wfalltst; winplt; close('all');
exit;
----------------------------------------------------------------------------
This function simply starts every example program included in the demo folder of my plt file exchange submission. This startup function (in total) creates and then deletes the following graphic objects:
35 figure windows
2384 line objects
970 uicontrols
893 text objects
273 axes
195 uicontext menus
13 uimenu objects
4 patch objects
2 image objects
Then I timed the whole mess by running batch files such as this, (the difference between the start & end times are reported below):
--------------------------------------------------
@ECHO OFF
ECHO Start time = %Time%
start /b /wait F:\Matlab2015a\bin\matlab.exe -wait
ECHO End time = %Time%
--------------------------------------------------
I noticed that the batch file would run faster the 2nd time, probably because Matlab starts much faster once the disk cache has been loaded. So to average out this effect and other random variations, I ran it 3 times and reported the average batch file execution time:
R2015a: 45.99 sec
R2009b: 24.84 sec
R12.1: 10.25 sec
BCC55: 7.09 sec
I had to make minor changes to the startup.m function to get it to compile, but the differences were not material and didn't change the number or type of graphics objects that were created. Lest you think this must be a measurement error, I can tell you that the difference is obvious even without any numbers. The figures fly up onto the screen in the older version so fast that there would not even be a hope of counting the figures as they appear. Not so with R2015a. Also I have carefully checked each of the 35 figure windows to make sure they look and behave the same in all four of the above scenarios. I would have also compared with a version compiled with the R2015a compiler if I had it, although I have been told that it wouldn't be any faster than R2015a itself.
My apologies to TMW if I've maligned their latest version by not using the appropriate hardware, but still one has to admire the Mathwork's programmers of two decades ago. They must have known a thing or two about writing efficient code even for modest hardware.
Perhaps all this talk about speed is misguided in the end. I have to admit that for the many matlab projects I have worked on over the last couple of decades, execution speed was not really an issue perhaps 99% of the time. It's usually been more about rapid development. On the other hand, I find it more fun to work with efficient, snappy software. It would be one thing if the new versions represented some kind of paradigm shift enabling more rapid development, but I haven't seen evidence of this. In fact I haven't found anything I can do easily in R2015a that I can't do just as quickly in R12.1.
By the way if anyone wants the BCC55 compiled version of the startup file so you can do your own comparisons I would be happy to share it with you. It's only a 4.9 Mbyte zip file which includes the executable and all required DLLs. (Matlab doesn't have to be on the machine). If you think I meant to type Gbyte ... no - it really is that small :) It only runs on a windows machine however (winXP thru Win10) as I don't know how to compile for a Linux machine. One of the 35 figure windows created in this compiled version is the pltsq figure used in line animation speed test that I discussed above, so you can also use this for your own line animation comparisons.
Bruno Luong
Nov 15, 2016, 2:35:08 AM11/15/16
to
IMHO, the "animated line" is quite nice. It force the programmer to get close to the optimal speed whatever the engine behind allows (read HG2).
Paul Mennen
Nov 16, 2016, 9:50:08 AM11/16/16
to
"Bruno Luong" wrote
All the examples I have seen that demonstrate the use of this new object show how to plot a trace that is growing using it's "addpoints" feature (something that you can't do directly with the old line object). However my experiments do not seem to indicate that animated line objects help overcome the speed issues of the new graphics engine when creating oscilloscope like plots that update in real-time based on data from files, calculations, and/or user mouse movement (as in many of the plotting demos I mentioned in my previous message post).
I'm interested to see if anyone else has a different experience, but otherwise I'll stick with the measurements I presented in my previous post comparing the performance of the new/old graphics engines.
~Paul
> IMHO, the "animated line" is quite nice.
That doesn't say much Bruno. What do you like about it?
All the examples I have seen that demonstrate the use of this new object show how to plot a trace that is growing using it's "addpoints" feature (something that you can't do directly with the old line object). However my experiments do not seem to indicate that animated line objects help overcome the speed issues of the new graphics engine when creating oscilloscope like plots that update in real-time based on data from files, calculations, and/or user mouse movement (as in many of the plotting demos I mentioned in my previous message post).
I'm interested to see if anyone else has a different experience, but otherwise I'll stick with the measurements I presented in my previous post comparing the performance of the new/old graphics engines.
~Paul
Bruno Luong
Nov 16, 2016, 10:07:07 AM11/16/16
to
"Paul Mennen" wrote in message <o0hrmr$i88$1...@newscl01ah.mathworks.com>...
Independently of HG1 and HG2, if user wants to create an osciloscope-like windows, they should not plot a big array then zoom in using xlim.
They should create a small buffer of XData and YData and update this buffer when new data come, such as a circular buffer.
Unfortunately, the way MATLAB graphic interfacing with user data, you must update the entire array for adding a single data.
ANIMATED line does that with very simple syntax, and non-experience user can use it in a freindly way. Furthermore they might optimize it internally to avoid data copying.
But I must admit I seldom use it because I need my code to be compatible with older MATLAB version.
> "Bruno Luong" wrote
> > IMHO, the "animated line" is quite nice.
>
> That doesn't say much Bruno. What do you like about it?
>
> All the examples I have seen that demonstrate the use of this new object show how to plot a trace that is growing using it's "addpoints" feature (something that you can't do directly with the old line object). However my experiments do not seem to indicate that animated line objects help overcome the speed issues of the new graphics engine when creating oscilloscope like plots that update in real-time based on data from files, calculations, and/or user mouse movement (as in many of the plotting demos I mentioned in my previous message post).
I never said animated line overcomes speed of HG2, in contrary.
> > IMHO, the "animated line" is quite nice.
>
> That doesn't say much Bruno. What do you like about it?
>
> All the examples I have seen that demonstrate the use of this new object show how to plot a trace that is growing using it's "addpoints" feature (something that you can't do directly with the old line object). However my experiments do not seem to indicate that animated line objects help overcome the speed issues of the new graphics engine when creating oscilloscope like plots that update in real-time based on data from files, calculations, and/or user mouse movement (as in many of the plotting demos I mentioned in my previous message post).
Independently of HG1 and HG2, if user wants to create an osciloscope-like windows, they should not plot a big array then zoom in using xlim.
They should create a small buffer of XData and YData and update this buffer when new data come, such as a circular buffer.
Unfortunately, the way MATLAB graphic interfacing with user data, you must update the entire array for adding a single data.
ANIMATED line does that with very simple syntax, and non-experience user can use it in a freindly way. Furthermore they might optimize it internally to avoid data copying.
But I must admit I seldom use it because I need my code to be compatible with older MATLAB version.
ThomasB
Sep 14, 2017, 7:42:17 AM9/14/17
to
Are there any updates on the speed issues of the HG2 graphics engine?
I just tried R2017a, and my zooming for my plots (with many markers/data points) is slow, 1 second lag.
I will continue to stick with R2014a, where the zooming is instantaneous.
It is a shame that new releases continue to have worse usability than older versions, even after three years.
I just tried R2017a, and my zooming for my plots (with many markers/data points) is slow, 1 second lag.
I will continue to stick with R2014a, where the zooming is instantaneous.
It is a shame that new releases continue to have worse usability than older versions, even after three years.
Bruno Luong
Sep 14, 2017, 8:24:18 AM9/14/17
to
"ThomasB" <t...@ellipticlabs.com> wrote in message <opdpud$6br$1...@newscl01ah.mathworks.com>...
I end up create my own plotting/zooming tools by limiting the number of points in the curves to few thousands by subsampling. More than that just forget HG2.
Bruno Luong
Sep 22, 2017, 7:34:19 AM9/22/17
to
Just make few quick tests with R2017b, can't see any obvious speed improvement with R2017a (bar animation is even slightly slower, with new default color and more flexible color setting).
I see in the Release Notes that "Tall Array Support: Visualize out-of-memory data using plot, scatter, and binscatter" with zooming supported.
Not sure if one can hack it to improve speed of large data.
I see in the Release Notes that "Tall Array Support: Visualize out-of-memory data using plot, scatter, and binscatter" with zooming supported.
Not sure if one can hack it to improve speed of large data.
Igor Matlab
Nov 6, 2017, 5:44:16 AM11/6/17
to
I went from 2012a to 2017a, and now it takes approximately 1600x longer for a surf command to execute....
On 2012a:
>> clear all, close all
>> load('d:\temp\dFh.mat')
>> whos dFh
Name Size Bytes Class Attributes
dFh 1100x500 4400000 double
>> tic, surf(dFh), drawnow, toc
Elapsed time is 0.336961 seconds.
On 2017a:
>> clear all, close all
>> load('d:\temp\dFh.mat')
>> whos dFh
Name Size Bytes Class Attributes
dFh 1100x500 4400000 double
>> tic, surf(dFh), drawnow, toc
Elapsed time is 533.813392 seconds.
I'm in contact with matlab support, but they haven't found any solution so far, anyone else have better luck?
System details are below.
Best Regards,
Igor
Operating System: Windows 7 Professional, 64-bit (Service Pack 1)
DirectX version: 11.0
GPU processor: Quadro FX 3800
CUDA Cores: 192
Total available graphics memory: 4607 MB
Dedicated video memory: 1024 MB GDDR3
Shared system memory: 3583 MB
System Manufacturer: Hewlett-Packard
System Model: HP Z800 Workstation
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 44 Stepping 2 GenuineIntel ~2794 Mhz
BIOS Version: Hewlett-Packard 786G5 v03.15, 29-Oct-2010
Total Physical Memory: 24,559 MB
Virtual Memory: Max Size: 49,117 MB
On 2012a:
>> clear all, close all
>> load('d:\temp\dFh.mat')
>> whos dFh
Name Size Bytes Class Attributes
dFh 1100x500 4400000 double
>> tic, surf(dFh), drawnow, toc
Elapsed time is 0.336961 seconds.
On 2017a:
>> clear all, close all
>> load('d:\temp\dFh.mat')
>> whos dFh
Name Size Bytes Class Attributes
dFh 1100x500 4400000 double
>> tic, surf(dFh), drawnow, toc
Elapsed time is 533.813392 seconds.
I'm in contact with matlab support, but they haven't found any solution so far, anyone else have better luck?
System details are below.
Best Regards,
Igor
Operating System: Windows 7 Professional, 64-bit (Service Pack 1)
DirectX version: 11.0
GPU processor: Quadro FX 3800
CUDA Cores: 192
Total available graphics memory: 4607 MB
Dedicated video memory: 1024 MB GDDR3
Shared system memory: 3583 MB
System Manufacturer: Hewlett-Packard
System Model: HP Z800 Workstation
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 44 Stepping 2 GenuineIntel ~2794 Mhz
BIOS Version: Hewlett-Packard 786G5 v03.15, 29-Oct-2010
Total Physical Memory: 24,559 MB
Virtual Memory: Max Size: 49,117 MB
Yair Altman
Nov 6, 2017, 10:11:19 AM11/6/17
to
"Igor Matlab" <igor.d...@sbmoffshore.com> wrote in message <otpedo$c1a$1...@newscl01ah.mathworks.com>...
About the only thing that has a chance of improving things for you is to ensure that you have the latest graphics driver (download & install if necessary) and that your Matlab recognizes it - run opengl('info') to ensure that Software=false (i.e., using hardware acceleration) - if it is true then you're running on OpenGL's slow software emulation, so try to force it to use the hardware accelerator using opengl('hardware').
Note that even then, it will still be [much] slower than in your R2012a, but hopefully not by a factor of 1600x but rather by a much more acceptable factor.
If it's still not acceptable, you would need to modify your code (for example, plot far fewer data points).
Yair Altman
http://UndocumentedMatlab.com
Author: "Accelerating MATLAB Performance" (CRC Press, 2014)
> I went from 2012a to 2017a, and now it takes approximately 1600x longer for a surf command to execute....
[snip]
About the only thing that has a chance of improving things for you is to ensure that you have the latest graphics driver (download & install if necessary) and that your Matlab recognizes it - run opengl('info') to ensure that Software=false (i.e., using hardware acceleration) - if it is true then you're running on OpenGL's slow software emulation, so try to force it to use the hardware accelerator using opengl('hardware').
Note that even then, it will still be [much] slower than in your R2012a, but hopefully not by a factor of 1600x but rather by a much more acceptable factor.
If it's still not acceptable, you would need to modify your code (for example, plot far fewer data points).
Yair Altman
http://UndocumentedMatlab.com
Author: "Accelerating MATLAB Performance" (CRC Press, 2014)
Igor Matlab
Nov 6, 2017, 12:36:19 PM11/6/17
to
Hi Yair,
I had tried the things you suggested, but I didn't realize that the following statement in my startup.m file overruled those commands:
set(0, 'DefaultFigureRenderer', 'painters')
That statement was there from the "zbuffer" days but removing that statement gave more or less normal performance.
I recall that painters rendering was always superior to opengl rendering and inferior to zbuffer rendering, maybe this has changed now?
Best Regards,
Igor
"Yair Altman" wrote in message <otpu2c$f99$1...@newscl01ah.mathworks.com>...
I had tried the things you suggested, but I didn't realize that the following statement in my startup.m file overruled those commands:
set(0, 'DefaultFigureRenderer', 'painters')
That statement was there from the "zbuffer" days but removing that statement gave more or less normal performance.
I recall that painters rendering was always superior to opengl rendering and inferior to zbuffer rendering, maybe this has changed now?
Best Regards,
Igor
"Yair Altman" wrote in message <otpu2c$f99$1...@newscl01ah.mathworks.com>...
0 new messages