# MATLAB R2014b Graphics – Part 3: Compatibility Considerations in the New Graphics System43

Posted by Loren Shure,

Today, David Garrison, our guest blogger, will continue his series on the new graphics system in R2014b.

• Part 1: Features of the New Graphics System
• Part 2: Using Graphics Objects
• Part 3: Compatibility Considerations in the New Graphics System

Here is Part 3 of the series.

### Contents

#### What have we learned so far?

In Part 1 of this series, I provided an introduction to the new MATLAB graphics system in R2014b with descriptions of a number of new features. In Part 2, I talked about one of the big changes in R2014b -- graphics functions return MATLAB objects, not numeric handles. In this post, I will talk about compatibility considerations in using R2014b graphics.

This post is longer than my two previous posts. In the first section, I'll talk about the kind of changes we've made in R2014b graphics, why we made those changes, how they affect you, and where to go for more information. The second section describes visual changes in the new graphics system including a new colormap, new line colors in plots, and new sizes for plot titles and axis labels, and these affect everyone. The last section is about changes we've made that affect advanced graphics users and user interface builders. Most of you can skip the more advanced material in the last section.

#### Section 1: Compatibility Considerations for R2014b graphics

When we talk about compatibility considerations we are talking about changes in R2014b that may not be compatible with code written before R2014b. These incompatibilities can affect your code in one of three ways.

1. A visual change that affects how a plot looks
2. A change that affects the behavior of your code
3. A change that causes an error that will require you to modify your code

#### Why did we make these changes?

First of all, let me say that here at MathWorks we take compatibility very seriously. We have a rigorous process for vetting potential changes in MATLAB that may affect existing MATLAB code. We evaluate them very thoroughly to determine the extent of their impact. We document those changes in our release notes and provide alternatives whenever possible. Those changes are necessary to allow us to continue to develop MATLAB.

One of our goals for the new graphics system was to introduce a new architecture that would allow us to build new graphics capabilities for the future. We couldn't continue with the old graphics architecture because it was too limiting. The new architecture has also allowed us to fix a large number of outstanding graphics bugs that have accumulated over the years.

Our second goal was to support existing graphics functionality and to minimize the disruption to MATLAB users. We did that by evaluating every change that would introduce an incompatibility in the graphics system. We tested those changes in house with over 100,000 MATLAB files and in person with a large number of advanced graphics users to determine the following:

• How often will a particular incompatibility affect user code?
• Which users will be impacted?
• How hard will it be to identify the effect of a specific incompatibility?
• How much work will be required if code changes have to be made?

The results of all this testing allowed us to do two things. First, it allowed to make changes in the new graphics system before the release to minimize the effect of certain incompatibilities. Second, it told us what kind of documentation and tools would be required to help people make the transition.

#### How do the changes affect me?

Anyone using graphics will notice a visual difference in R2014b. People who've seen R2014b tell us the new visual appearance is a big improvement over previous versions of MATLAB. Differences include changes to colormaps, line colors, font sizes, grids, and other visual properties. For most people that's it. That's all you need to know.

Those of you who do advanced graphics programming and build user interfaces may be affected by incompatibilities that will require changes to your code. I'll talk about the most common ones in the last section of this post. We've also provided plenty of documentation and some tools to help you make the transition.

#### How do I find out more about the changes in R2014b graphics?

In preparation for the release of the new graphics system, we created a lot of material to help people understand the changes and make any modifications to their code. Here is a list of resources for information on R2014b graphics:

#### Section 2: Visual Differences

Anyone who uses MATLAB graphics in R2014b will see that plots look quite different. In this section, I will show you some of the big visual differences. As we go through these examples, I think you'll agree that the changes in R2014b are a big improvement over previous MATLAB versions. Of course, there may be times when you may want to change some of these visual properties. I will either tell you how to do that or I will provide a link to the documentation for more information.

#### The New Default Colormap

In MATLAB, the colormap is a matrix of RGB color values used to set the colors for images and surfaces. For example, when you call the surf function you get a plot where the surface color is proportional to the height of the plot. Colors are based on the values from the colormap.

In R2014b, we introduced a new colormap called parula which is now the default. In previous versions of MATLAB, the default colormap was jet. Here's a comparison of the colormaps between R2014a and R2014b.

We changed the default colormap to address problems with rainbow colormaps like jet. The new parula colormap is ordered from dark to light and is perceptually uniform. For more information about the issues with rainbow colormaps like jet, see the post on Steve Eddins blog called A New Colormap for MATLAB – Part 2 – Troubles with Rainbows. You can use the colormap function to change the colormap to whatever you want it to be. For example, to change the colormap to jet use the following command after you create your plot.

colormap(jet)


#### Line Colors in Plots

We've also changed the lines colors used for plots. These line colors were selected to make lines easier to distinguish and to help people with certain types of color blindness.

The line colors used in plots are controlled by the ColorOrder property of the Axes object. One other note regarding line colors in plots. In R2014b, when plot is called with hold on, MATLAB will use the next color in the color order for each call to plot. That gives plots with different line colors. In previous versions, each call to plot would start over in the color order so that each line would be the same color.

For information on controlling the colors in the ColorOrder see the documentation section Why Are Plot Lines Different Colors?

#### Plot Titles and Labels

One last change regarding appearance of plots. In R2014b, plot titles and axis labels use a larger font size than in previous versions of MATLAB and plot titles are bold by default.

I intentionally used a very long title in this plot to make a point. In this case, the title is so long it extends beyond the boundaries of the axes. You can control your plot title and axis labels using the TitleFontWeight, TitleFontSizeMultiplier, and LabelFontSizeMultiplier properties. For more information see How Do I Make the Graph Title Smaller?

That covers the major visual changes for plots in R2014b. The next section covers changes that only affect advanced graphics users and GUI builders.

Most of you can stop reading here and get on with the rest of your day.

#### Section 3: Changes that Affect Advanced Graphics Users

If you are still reading, I assume you do some advanced graphics programming in MATLAB or maybe you build MATLAB user interfaces. In this section I'm going to cover the four most common non-visual changes in R2014b graphics that you are likely to encounter. If you do encounter one of these, you will probably have to make changes to your code.

#### Graphics Functions Return Objects, not Numeric Handles

I mentioned this briefly in Part 2 of this series. Graphics functions now return objects, not numeric handles. The R2014b documentation has detailed information about this subject in the section called Graphics Handles Are Now Objects, Not Doubles. I will give a couple of simple examples to illustrate what can happen with code written before R2014b.

Prior to R2014b, you could store a set of handles to graphics objects in an array and then add some numeric data to that array. In R2014b, that will cause an error.

x = -pi:0.1:pi ;
y1 = sin(x);
y2 = cos(x);
myLines = plot(x,y1,x,y2)    % plot returns an array of two Line objects


If you then try to set myLines(3) = 1.2, you get the following error.

  Cannot convert double value 1.2 to a handle

MATLAB won't let you add numeric values to an array of graphics objects. A similar problem occurs if you try to use an object handle in a function where MATLAB expects a numeric value. A simple example of this happens with the sprintf function.

a = sprintf('You clicked on figure %d\n', gcf);


The %d specification in the sprintf format string expects an integer value. However, since gcf is a figure object, you get the following error.

  Error using sprintf
Function is not defined for 'matlab.ui.Figure' inputs.

Here is one final example. Because graphics handles used to be numbers, you could use them in logical expressions.

if (get(0, 'CurrentFigure'))
disp(['Figure ' get(gcf, 'Name')'])    % display the figure name for gcf
else
disp('No open figures')                % there is no open figure
end


This worked in earlier versions of MATLAB because get(0,'CurrentFigure') would return either an empty array or a numeric figure handle. Both of these values are valid in the logical test of the if statement above. In R2014b, this will cause an error.

  Conversion to logical from matlab.ui.Figure is not possible.

We have tried to maintain compatibility with previous releases in some cases. For example, you can still use 0 to refer to the graphics root in functions like get and set. As a best practice, however, we now recommend using the groot function to get the graphics root. Similarly, we still support the use of literal integer values to refer to figures in functions like set, get, and figure. Again, the best practice is to use a variable which contains the object when using these functions.

If you find yourself really stuck, it is possible to cast object handles to numeric handles using the double function. You can then cast the number back to an object handle using the handle function. We don't recommend this as a long term solution. Be aware that we may choose to remove this feature in a future version of MATLAB. If we do, we'll let you know in advance.

#### Colorbars and Legends are No Longer Axes

In earlier versions of MATLAB, the legend and colorbar functions created objects whose type was 'axes'. Technically, legends and colorbars were subclasses of axes. In R2014b, the legend function creates a Legend object and the colorbar function creates a ColorBar object.

So what does that mean? First, the results of a findobj call in R2014b may be different than in previous versions. In R2014b, the command

findobj('Type', 'Axes')


will not return any legend or colorbar objects. To get those objects you will need to do the following:

findobj('Type', 'Legend')
findobj('Type', 'ColorBar')


Second, legends and colorbars cannot become the current axes. Prior to R2014b, you could write code that looks like this:

plot(1:10)
cb = colorbar;
axes(cb)                % Make the colorbar the current axes
title('My Colorbar')    % set the title of the colorbar


If you try to run this code in R2014b you will see an error.

  Error using axes
Handles of type ColorBar cannot be made the current axes

In R2014b, you can still use the title function. Just give it the colorbar handle as the first argument.

title(cb, 'My Colorbar')


Alternatively you can use the colorbar's Label property to get the text object for the label and set its string property.

cb.Label.String = 'My Colorbar'


#### Objects Returned by Certain Charts Have Changed

Charting functions like bar, contour, stem and others return one or more graphics objects. In previous versions of MATLAB, those objects had names like barseries, contourgroup, and stemseries. These objects were each a special type of object called an hggroup. Each of these hggroup objects had a set of children. The children were low level objects like lines or patches. Here is an example from R2014a.

[~,h] = contour(peaks, 'LineLevels', -6:1:8) ;
get(h, 'Type')        % an hggroup object is returned by the contour function

  ans =
  hggroup
ch = get(h, 'Children') ;
get(ch(1), 'Type')    % the children of the hggroup are patch objects

  ans =
  patch

Prior to R2014b, the contour command returned an hggroup object that had children that were patch objects (one for each contour line). Using the patch objects, it was then possible to do interesting things with the contour lines. You could, for example, make the even numbered contour lines solid and make the odd numbered contour lines dashed as shown below.

As you've probably guessed, things are different in R2014b. First, the types of the objects returned by these functions are different. For example, the bar function returns a Bar object and the contour function returns a Contour object. Second, the objects returned by these functions no longer have any children. That means you can't get to the low-level objects.

So what do you do? You have to take a different approach. In the code below, I've create two contours -- one with solid lines and one with dashed lines. This code will create a plot like the one shown above. It works in R2014b and in previous versions of MATLAB.

major = -6:2:8;
minor = -5:2:7;
[~,hmajor] = contour(peaks,'LevelList',major);    % contour with even-numbered levels

hold on
[~,hminor] = contour(peaks,'LevelList',minor);    % contour with odd-numbered levels
set(hminor,'LineStyle',':')                       % make the odd-numbered levels dotted
hold off


#### UI Controls May Not Appear in a GUI

There is one last change that I want to talk about. It can affect MATLAB GUIs created before R2014b. Suppose I have a simple GUI with a panel and a button. I might have code that looks something like this:

figure('NumberTitle', 'off', 'Name', version('-release'), ...
'Position', [100 100 350 260], 'MenuBar', 'none', 'Toolbar', 'none') ;
button = uicontrol('Style', 'pushbutton', 'String', 'My Button', ...
'Units', 'normalized', 'Position', [0.4 0.5 0.25 0.15]) ;
panel = uipanel('Position', [0.10 0.10 0.8 0.8], 'Title', 'My UIPanel') ;


Seems OK right? Here's what it looks like in R2014a and R2014b.

So what happened here? I don't see my button in R2014b. Where did it go? It turns out that the button is still there but in R2014b it is drawn under the panel.

In previous versions of MATLAB, uicontrols were always drawn on top on uipanels regardless of the order in which they were created. In R2014b, the two components are drawn in creation order. Since the panel was created after the button, it is drawn on top. What I really want is to have the button be a child of the panel. In order to do that, I can change my code to look like this:

figure('NumberTitle', 'off', 'Name', version('-release'), ...
'Position', [100 100 350 260], 'MenuBar', 'none', 'Toolbar', 'none') ;
panel = uipanel('Position', [0.10 0.10 0.8 0.8], 'Title', 'My UIPanel') ;
button = uicontrol('Parent', panel, 'Style', 'pushbutton', 'String', 'My Button', ...
'Units', 'normalized', 'Position', [0.4 0.5 0.25 0.15]) ;


You can also fix this problem in GUIDE by moving the button out of the panel and then moving it back in. This will automatically make the button a child of the panel.

#### Have you encountered any incompatibilities?

Have you encountered any of these changes in R2014b? Have you been able to find the information you need? Have you been able to use this information to make necessary changes to your code? Have you tried the transition tools? We'd love to hear your thoughts here.

#### Conclusions

I am hopeful that this series of posts has given you a good introduction to the R2014b graphics system. There's a lot of new stuff to digest in this release. Try these things out and let me know what you think.

Thanks to Loren for letting me take over her space for the last few weeks.

Get the MATLAB code

Published with MATLAB® R2014b

### Note

NB replied on : 1 of 43
There are several things that bother me a lot in the new system (I have upgraded directly from 2011b to 2014b):

(1) I used to produce eps figures with a set size using paperposition property of the figure and then using the print command with -depsc option. Running the same bit of code with the update now produces the figure inside an A4 bounding box, and weirdly I have to use the -loose option to make it come back to its set size. Is this a known issue and is there a workaround which does not include me rewriting all my figure making scripts ?

(2) Matlab now systematically uses an hyphen instead of a proper minus sign (there is a clear difference !) in axes tick labels. There are generated automatically and I could not find any way to change that. Is there a way to control this ?

Thanks very much !
SSH replied on : 2 of 43
1. How long will the new syntax be supported/maintained? Is TMW a 100%, 'no-compromises' behind this revision? There are a lot of syntax features that will definitely break in multiple projects now (even though I did a lot of testing with the -hgVersion switch) and I expect a lot more people will be annoyed than in 2012. So is there a chance that TMW will bend to community pressure and roll these changes back? 2. Is this a formal TMW buy-in into an Object Oriented environment? I personally love it. I have always detested the set/get method syntax. So is this a reflection on Matlab's future trajectory?
NG replied on : 3 of 43
I already mentioned this in the first post about the new graphical system. Although it looks way better, it is terribly slow if you have multiple figures open and try to zoom. Before anyone asks... I have upgraded the graphical drivers of my system. If you try to plot a huge dataset (which used to be one of the key features of Matlab above any other similar program) the matlab session slows down. Try to the following:
xx = randn(1e6, 1);
figure(10);
tic;
plot(xx,'x');
drawnow;
toc

After these commands, it takes about a minute before I am allowed to zoom. Although, the drawnow has finished, as toc is exectued. My result:
Elapsed time is 10.533855 seconds.

I know that it doesn’t make sense to try to plot as many points. However, this was possible in older versions. Results for 2014a:
Elapsed time is 0.567253 seconds.

For this reason our team will not upgrade our applications to R2014b, as our customers can no longer plot and interact quickly with the (huge) data sets as they used to do.
EH replied on : 4 of 43
The ALPHA function does not make AREA plots transparent in 2014b. I have also witness significant slow downs when switching between a large number of docked plots - something that was not an issue in earlier versions.
Eric replied on : 5 of 43
My biggest gripe, which is not addressed in this series, is pasting figures into PowerPoint now requires setting the 'renderer' property manually. With the default renderer of 'opengl', pasted figures do not support transparency despite the fact that the "Figure background color" option is set to "Transparent background" in the Copy Options dialog).

If the radio button in the Copy Options dialog box is non-functional, it should be removed. Otherwise it should be made to function as would be reasonably expected. Currently the behavior seems to be "Transparent background if renderer is set to painters, non-transparent background otherwise". This is not discussed in the "How to Print or Export" section of the documentation that is shown when the user selects the Help button from this dialog box, either.

As it is, I'm off to look up how to set the renderers property of newly created figures to 'painters' automatically and how to set the default colormap back to jet. I find it interesting that the example image for the different colormaps in this post (which I have seen numerous places elsewhere), uses a mesh map. In that case the information presented using color is also shown in a two other ways - height and mesh lines. It makes me think the Mathworks understands that parula has some visual deficiencies in representing information and needs to be augmented by other visual cues.

Eric replied on : 6 of 43
In case anybody's interested, here's how to change the default renderer to 'painters' and the default colormap to jet. perhaps some day these will be in the Matlab Preferences tool. Place the following in your startup.m file:

set(0,'DefaultFigureRenderer', 'painters');%Set default renderer to painters

set(0,'DefaultFigureColormap', jet);%Set default colormap to jet

David Garrison replied on : 7 of 43
SSH, We are commited to the new graphics system. When you say "So is there a chance that TMW will bend to community pressure and roll these changes back?", I assume you are referring to the change in handles from doubles to objects. We don't have any plans to go back to numeric handles although we have maintained compatibility in some areas as I mentioned above. You also have the option of using the double/handle functions to cast between double handles and object handles if you need to do that. We expect to expect to support those functions for the foreseeable future.
Toby Driscoll replied on : 8 of 43
Overall I'm happy with the visual changes (especially the colors changing after "hold on"). I would have hoped for more performance improvements for plots with a lot of data, but I expect those to come with time. The level of backward compatibility is pretty impressive, actually. I had to update my toolbox (https://www.mathworks.com/matlabcentral/fileexchange/1316-schwarz-christoffel-toolbox), which was first released in 1994 using MATLAB 4. The changes were to stop using EraseMode (not sure why that wasn't grandfathered in and ignored) and some places where I had pre-allocated numeric arrays for graphics handles (which was really a silly thing to do in the first place). Both were spotted by the automatic checking tool. It was tedious to fix them, but not a huge effort. When you look at other examples (ahem, Python 2/3), changes of this magnitude are pretty risky. But I had been feeling for some time that MATLAB graphics weren't aging well. And I welcome the nudge toward dot syntax overall. So you get an "attaboy" from me.
David Garrison replied on : 9 of 43
EH, The issue with the alpha function is related to the change I described in the section "Objects Returned by Certain Charts Have Changed". It used to be that the alpha function would reach inside the area objects and get their children. Those children were patch objects whose alpha property could be set. Those children are not there in R2014b, so the alpha function has no effect on them. We are looking at ways to restore the ability to chnage transparency in area plots.
Matthew Dzieciuch replied on : 10 of 43
I agree with NG, there is something seriously wrong with the new graphics system that slows it down. The example is very telling: xx=randn( 1000000,1); tic; plot( xx, 'o'); drawnow; toc For me, with a new macbook pro with Mavericks, it takes 0.5s in2014a, and varies from 3 to 14s under 2014b. This test is very simple, and makes me wonder if anyone at the Mathworks really tested it despite what Dave Garrison said above. And in case you think that a change from 0.5 to >3s is trivial, just try it with 10^7 points instead of 10^6.
David Garrison replied on : 11 of 43
NG and Matthew, Yes, there is a significant slowdown when plotting a large data set with circle markers. We are looking into why this is happening and how to improve the performance. In the meantime, using point markers ('.') is much faster if that helps. Dave
NG replied on : 12 of 43
Hi David, What I don't understand is why this is not mentioned at all in the release notes. Matthew and I can't be the first users who noticed this. In fact, I have already send a feedback report in August (during the pre-release). Therefore this issue was already known. As said before, we will recommend are customers not to update to R2014b until this issue is resolved. Can you provide a link to the bugreport, such that users as Matthew and myself can follow this?
Andreas replied on : 13 of 43
Hi, i had some issues with an old script: hAllFigs = findobj(groot,'Type','figure'); hFigs = sort(hAllFigs( hAllFigs~=hGui )); %Omit the GUI-figure. 'sort' function does not apply to the new handle objects. The solution was to make a neat little function that takes in a figure handles array, sorts it based on the 'Number' property of the figure handles and returns a figure handles array with figures listed in ascending og descending order.
Michael Tombs replied on : 14 of 43
R2014b is unusably slow with reasonable amounts of data. Matlab has always been at plotting/printing figures for me, so producing a 12 page pdf could take 30 seconds - but I can't accept 5 minutes! I also have the pan/zoom issue, and don't use circle to plot. The 10-20 factor speed reduction is related to huge increase in amounts of ram being used. Apparently the print speed issue is a known bug? https://www.mathworks.com/matlabcentral/answers/157920-printing-figures-very-slow-2014b-vs-2013b but I also haven't found the formal bug report to subscribe to, so will now wait to see what R2015a brings before considering moving from R2014a.
Michael Tombs replied on : 15 of 43
Just noticed the change to 'hold', this change is a removal of functionality - have always been able to continue the colour cycle with "hold all", in R2014b 'hold on' is made to work the same as 'hold all' and help says "hold all" is obsolete and will be deleted in future. So how can you continue plotting with same colour in R2014b?
MNewman replied on : 16 of 43
I think that the change to "hold on" (to do what "hold all" used to do) is probably sensible. Of course, those of us who knew the distinction won't benefit from this.

However, I do want the old behaviour of "hold on" from time to time, so I'd appreciate a replacement, e.g. "hold lines". For example, to demonstrate the effect of interpolation

t1 = 1:7;
t2 = linspace(0,8,100);
plot([cos(t1); sin(t1)], 'o')
hold on
plot([cos(t2); sin(t2)], '-')

Further, I don't see the need to break old code using "hold all" by withdrawing this feature (as threatened in the documentation).
David Garrison replied on : 17 of 43
Folks, As Andreas has pointed out, you can't sort figure handles any more since the handles are no longer doubles. Here is some code that will sort a set of figures based on their Number property. hAllFigs = findobj(groot,’Type’,'figure’); [~,idx] = sort(cell2mat(get(hAllFigs,'Number'))); % Sort the figure Numbers hAllFigs = hAllFigs(idx); % Reorder the figures array Dave
David Garrison replied on : 18 of 43
Regarding the questions about hold behavior, their are at least two ways to get the old behavior with all lines of the same color. Option 1 is to use the ColorOrderIndex property of the Axes like this: plot(1:10,sin(1:10)) hold on ax = gca ; ax.ColorOrderIndex = 1; plot(1:10,cos(1:10)) This will reset the color to the first one (blue) before plotting the next curve. The downside of this approach is that you have reset the ColorOrderIndex before each of the subsequent plot commands. Option 2 is to set the ColorOrder of the Axes to use a single color. Then all subsequent plots will use that single color. That code looks like this: plot(1:10,sin(1:10)) hold on ax = gca ; ax.ColorOrder = ax.ColorOrder(1,:); plot(1:10,cos(1:10)) The ColorOrder only has to be set once. It then applies no matter how many times you plot into that Axes. Dave
Bruce Elliott replied on : 19 of 43
I don't see the new uitab functions in GUIDE. Are they hiding in there somewhere, or will we have to wait a little longer for them to show up?
John replied on : 20 of 43
The plot examples given look great. In the past releases, it took substantial doctoring to produce plots that were "presentation quality". These ones appear fantastic right out of the box. One change I'm really curious about - has the amount of waste space in a figure containing a plot been reduced at all? I know there is doctoring that can be done to mitigate the wastage, but it never seems quite enough.
David Garrison replied on : 21 of 43
John, Positioning of Axes withing a figure window has not changed. You can play around with properties like Position or TightInset if you want to use smaller margins around the Axes.
NG replied on : 22 of 43
Hi David, Care to follow-up my question as well? I'd like to see the buglist, where I can mark 'this issue affects my work'. Maybe, though not likely, TMW is then triggered to solve something. NG
David Garrison replied on : 23 of 43
NG, Sorry. It takes a few days for a bug report to be published. The one related to marker performance is 1133574. You can find it at this URL: https://www.mathworks.com/support/bugreports/1133574. Thanks, Dave
Karin replied on : 24 of 43
Hello, Thanks for providing all this detailed info on the graphics changes. I did want to point out a potential incompatibility. In making adjustments to the formatting of my error bars (and especially the widths of the upper and and lower caps) I have taken great advantage of the example provided here: https://blogs.mathworks.com/loren/2007/12/11/making-pretty-graphs/#. However, this approach no longer seems to work in 2014b, as the error bars seem to lack any Children. Thoughts? Apologies if the answer is obvious, and I haven't stumbled upon it.. Happy New Year -- Karin
David Garrison replied on : 25 of 43
Karin, This is a result of what I described in the section called "Objects Returned by Certain Charts Have Changed". We are looking into alternative ways to change the widths of the line caps in errorbar plots. Thanks, Dave
Zhen Jiang replied on : 26 of 43
Hello David, I'm not sure whether it has been reported before, but I have a hard time in generating good pdf figures in R2014b. Let me start with a very simple example here: % generate some data x = 0:0.1:2; y1 = -(x-1).^2+1.2; y2 = -(x-1).^2+0.8; % fill some area h = figure; hold on fill([x,fliplr(x)],[y1,fliplr(y2)],[0.9 0.9 1],'EdgeColor',[0.9 0.9 1]) % plot a circle plot(1,1,'o','MarkerSize',12,'MarkerEdgeColor','k','MarkerFaceColor','g') ylim([-3,3]) % save to PDF print(h,'-dpdf', '-painters', '-r2400', 'Fig.pdf'); It turns out that R2014b gives me a drastically different result than R2014a. The circle looks like a polygon, and the filled area has many weird white lines in it. Here is the link for the PDF figures I generated (I'm using Win8.1 x64, with the latest AMD display driver): https://www.dropbox.com/s/a2gy8pkx60kg3tm/Comparison_R2014a%26R2014b.zip?dl=0 Would you kidnly give me some insights about this issue? Thanks in advance! -- Zhen
David Garrison replied on : 27 of 43
Zhen, Could you open a Service Request for this one? You can do that through our Technical Support site: https://www.mathworks.com/support/contact_us Our support team should be able to help. Thanks, Dave
Lucy replied on : 28 of 43
I want to put rotated labels on a contour plot specifiying their fontsize and color and spacing. This does not seem to be possible with 2014b. I can either have horizontal labels with the text modifications or rotated labels with the required spacing but both. Is there a way round this?
David Garrison replied on : 29 of 43
Lucy, Are you referring to the labels for the contour levels or the tick labels on the x-axis? Thanks, Dave
Thomas replied on : 30 of 43
How can we now track changes of specific graphical properties? This line that worked fine in R2014a: addlistener(hf,'Position','PostSet',@(u,e)updatepos(P)); now generates the following error: Error using matlab.ui.Figure/addlistener While adding a PostSet listener, property 'Position' in class 'matlab.ui.Figure' is not defined to be SetObservable. Is there a reason why the 'position' property is not defined as SetObservable in the new graphical system?!
Lucy replied on : 31 of 43
I am referring to labels for the contour levels
David Garrison replied on : 32 of 43
Thomas, In R2014b, there are two new events for figures called 'SizeChanged' and 'LocationChanged. You should use these inside of listening for a PostSet event on the Position property. For example: f = figure ; lh1 = addlistener(f, 'LocationChanged', @(src, event) disp('Location Changed!)) ; lh2 = addlistener(f, 'SizeChanged', @(src, event) disp('Size Changed')) ; Thanks, Dave
David Garrison replied on : 33 of 43
Thomas, Sorry. My last comment should say "You should use these instead of listening for a PostSet event on the Position property." Dave
David Garrison replied on : 34 of 43
Lucy, Prior to R2014b, you could get a handle to all the text objects that are used to label the contour levels. These text objects were children of the contour object. In R2014b, objects returned by a charting function like contour do not have children so the underlying text objects are no longer accessible. We will look into ways to provide some additional control over contour label text in a future release of MATLAB. Dave
Lucy replied on : 35 of 43
In the meantime I must say it looks rather ugly.
Henry replied on : 36 of 43
Getting a colormap with 'lines' command gives completely different results in R2014a and R2014b. e.g. lines(3) How does that make any sense???
David Garrison replied on : 37 of 43
Henry, The lines function returns a colormap that is built from the ColorOrder (the colors used to draw lines in a plot). The default ColorOrder was changed in R2014b. That's why you are getting a different result. The ColorOrder was changed to make lines easier to distinguish and to help people with certain types of color blindness. If you wish, you can change the ColorOrder back to what it was in previous versions of MATLAB. See the documentation page https://www.mathworks.com/help/matlab/graphics_transition/why-are-plot-lines-different-colors.html for instructions on how to set the ColorOrder. Thanks, Dave
Stéphane replied on : 38 of 43
We switched back to R2013b because there's still some issues when using GUI Layout Toolbox and findjobj updates for HG2 (we were using a lot this toolbox and routine to overcome limitations of GUIDE/uicontrols). Fortunatly, HG2 is still appealing and we hope it will be a great step to ease creating advanced GUIs/Custom controls in next Matlab releases.
David Garrison replied on : 39 of 43
Stephane, You may know this already. There is a new version of the GUI Layout Toolbox on the File Exchange that is compatible with the R2014b graphics system. https://www.mathworks.com/matlabcentral/fileexchange/47982-gui-layout-toolbox If you are experiencing problems with the newest version of the toolbox, please contact the authors. I'm sure they would like to know about any issues that you have found. Thanks, Dave
Thomas replied on : 40 of 43
hello, this is a bug report following-up on the questions i asked earlier regarding detection of changes in object sizes: - i have successfully tested addlistener(f, ‘LocationChanged’, @(src, event) disp(‘Location Changed!)) ; (f being a figure handle), EXCEPT it does not generate an event when only the width of the figure is changed! - these new events 'LocationChanged' and 'SizeChanged' seem not to appear anywhere in the help thank you, Thomas
Tom Richardson replied on : 41 of 43
1, Dragging a control off and back on to a panel is not so easy when you can't see it to drag it off in the first place. 2. Is gui-layout-toolbox a replacement for GUIDE? Can you use it with a GUIDE created gui, or only with guis created with GLT? 3. I have controls on a panel, inside a bottom panel. The controls are invisible, and move-to-back appears to have no effect on the top panel. For all the talk about setting the parent property, it is not exposed in GUIDE. 4. Weird thing that happens. If I select a control in the object browser, then go to the GUIDE window and do move-to-front, then all the controls on its panel get drawn on top of the panel. But this doesn't persist when I change to another panel.
Bruce Elliott replied on : 42 of 43
I've encountered a problem that looks like it might be due to a bug in the updated version of the LEGEND function. Here is the line of code in question: [h,icons,plots,str] = legend(plotArr,strArr); where plotArr is a vector of line objects and strArr is a cell array of labels. If plotArr is a row vector, the returned array, plots, will be a column vector. If plotArr is a column vector, plots will be a row vector. This causes trouble for me in a function I wrote some time ago to add new entries to an existing legend. I concatenate the new array of line objects to the existing one, but since the array changes shape on each new call to legend(), it is unpredictable whether to concatenate as a row or as a column vector.
David Garrison replied on : 43 of 43
Bruce, That is a bug. I have reported it to our development team. If you had any further issues, please contact our Technical Support folks. Thanks, Dave