Re: (subplot changes) Outerposition Patch

[Ben Abbott]

On Feb 15, 2011, at 12:37 PM, bpabbott wrote:

> On Feb 15, 2011, at 11:55 AM, Konstantinos Poulios <address@hidden> wrote:
> 
>> On Tue, Feb 15, 2011 at 3:12 PM, Konstantinos Poulios
>> <address@hidden> wrote:
>> > On Tue, Feb 15, 2011 at 1:12 PM, Ben Abbott <address@hidden> wrote:
>> >>
>> >> On Feb 14, 2011, at 10:49 AM, Konstantinos Poulios wrote:
>> >>
>> >>> On Sun, Feb 13, 2011 at 11:29 PM, Ben Abbott <address@hidden> wrote:
>> >>>> On Feb 13, 2011, at 4:41 PM, logari81 wrote:
>> >>>>
>> >>>>> On Sun, 2011-02-13 at 14:49 -0500, Ben Abbott wrote:
>> >>>>>> On Feb 13, 2011, at 2:03 PM, Ben Abbott wrote:
>> >>>>>>
>> >>>>>> I've attached a changeset that decreases the margins between 
>> >>>>>> rows/columns. It looks to me like there remains to much space between 
>> >>>>>> the title and the axes position property. I haven't pushed this 
>> >>>>>> change as it looks to me like more needs to be done ..
>> >>>>>>
>> >>>>> I think subplots look much better with the factor 0.7 you have used in
>> >>>>> your patch.
>> >>>>>
>> >>>>> Concerning your question:
>> >>>>> " should the margins between the columns / rows be derived from the
>> >>>>> fontsize of the axis and its labels/title?"
>> >>>>>
>> >>>>> I would say, no. Because this is done now during position/outerposition
>> >>>>> synchronization.
>> >>>>
>> >>>> Can you give me a analytic description of how position/outerposition is 
>> >>>> synchronized? Also, how is the tightinset handled?
>> >>>>
>> >>>> For reference, the tightinset is the difference between the edges of 
>> >>>> the position and outerposition boxes. This it is 1x4 double whose 
>> >>>> elements are ordered as  [left bottom right top].
>> >>>>
>> >>>> The method Matlab uses is a bit convoluted.
>> >>>>
>> >>>>        
>> >>>> http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html
>> >>>>
>> >>>> The gnuplot backend uses a simple scheme. Effectively gnuplot behaves 
>> >>>> as ...
>> >>>>
>> >>>>        if (strcmp (get (gca, "activepositionproperty", "position"))
>> >>>>                position = get (gca, "position");
>> >>>>                inset = get (gca, "tightinset");
>> >>>>                outerposition = position + [-1,-1,1,1] .* tightinset;
>> >>>>        else
>> >>>>                outerposition = get (gca, "outerposition");
>> >>>>                inset = get (gca, "tightinset");
>> >>>>                position = outerposition + [1,1,-1,-1] .* tightinset;
>> >>>>        endif
>> >>>>
>> >>>> We don't actually have access to the values for the tightinset 
>> >>>> (internal to gnuplot). So it is only the values associated with the 
>> >>>> activepositionproperty that are reflected in the result.
>> >>>>
>> >>>> Matlab effectively does ...
>> >>>>
>> >>>>        if (strcmp (get (gca, "activepositionproperty", "position"))
>> >>>>                position = get (gca, "position");
>> >>>>                inset = get (gca, "tightinset");
>> >>>>                # grow outerposition to accommodate the position and 
>> >>>> tightinset, but the outerposition box never lies *inside* the 
>> >>>> specified/default value.
>> >>>>                # Meaning some method to remember the specified 
>> >>>> outerposition is needed.
>> >>>>                .
>> >>>>                .
>> >>>>                .
>> >>>>        else
>> >>>>                outerposition = get (gca, "outerposition");
>> >>>>                inset = get (gca, "tightinset");
>> >>>>                # shrink position to accommodate the outerposition and 
>> >>>> tightinset, but the position box never lies *outside* the 
>> >>>> specified/default value.
>> >>>>                # Meaning some method to remember the specified position 
>> >>>> is needed.
>> >>>>                .
>> >>>>                .
>> >>>>                .
>> >>>>        endif
>> >>>>
>> >>>> Is this the same or similar to what has been implemented?
>> >>>>
>> >>>> Personally, I'd be happy to pass on the Matlab approach and use the 
>> >>>> approach of gnuplot. But we should discuss that on the list before 
>> >>>> deviating from the Matlab standard.
>> >>>>
>> >>>>>> Specifically, I noticed that displaying the subplot demo is much 
>> >>>>>> slower. Is that due to "sync_positions"? What is happening here? Is 
>> >>>>>> the subplot function and the c++ side competing to synchronize the 
>> >>>>>> position/outerposition?
>> >>>>>>
>> >>>>> some certain overhead due to positions synchronization is to be 
>> >>>>> expected
>> >>>>> in general. I don't now if for subplots there is anything else that we
>> >>>>> should take into account. I will try to see if I can do some
>> >>>>> optimizations.
>> >>>>>
>> >>>>>> If that is the case, I think subplot.m should be rewritten and let 
>> >>>>>> the c++ synchronization of position / outerposition do its job.
>> >>>>>>
>> >>>>> Actually, I believe subplot should just create a layout for
>> >>>>> outerpositions of all subplots and let the c++ part decide for their
>> >>>>> positions.
>> >>>>
>> >>>> Ok. I'll have a cleared understanding of this if you respond to the 
>> >>>> questions above.
>> >>>>
>> >>>>>> Perhaps subplot() should only specify the outerposition, and let the 
>> >>>>>> c++ synchronization take care of the rest?
>> >>>>>
>> >>>>> With regard to the issue with legends in demo axis 4, I have identified
>> >>>>> the problem but I don't know how easy it is to fix. The legend position
>> >>>>> is actually calculated correctly, but after a title is added to the
>> >>>>> subplots the position of its axes changes and we have no way to tell
>> >>>>> legend to update its position accordingly. Would this be easy to
>> >>>>> implement with listeners in the frontend?
>> >>>>
>> >>>> A listener needs to be added that will triggers an update to the legend 
>> >>>> "position" when the "position" of the parent axes changes.
>> >>>>
>> >>>> I had thought that existed, but I see it is not there.
>> >>>>
>> >>>> Ben
>> >>>
>> >>> Actually the subroutine sync_positions in graphics.cc corresponds to
>> >>> the behavior you described for Matlab. There are only two exceptions
>> >>> with respect to the activepositionproperty=outrerposition case:
>> >>>
>> >>> 1. For 3D plots the inset depends on the position property, so that it
>> >>> cannot be calculated a priori. Currently in Octave the axes position
>> >>> is determined iteratively by shrinking gradually the position box and
>> >>> recalculating the new inset each time. Matlab doesn't do this, it
>> >>> seems to calculate position in one step using some approximation of
>> >>> the inset. The following video shows the positions behavior in Octave:
>> >>> http://ubuntuone.com/p/cYM/
>> >>>
>> >>> 2. I have set a lower limit for the automatic calculated position
>> >>> property at 20% of the width/height of outerposition. You can test
>> >>> this if you try too resize the plot window to tiny dimensions. In
>> >>> Matlab the axes will disappear, only labels will remain visible. In
>> >>> Octave axes will never disappear, the labels will be cropped if
>> >>> position width/height falls bellow 20% of outerposition.
>> >>>
>> >>> One comment: I haven't given access to the calculated tight inset
>> >>> values to the frontend yet, so get(h,'tightinset') still returns zeros
>> >>> but I am going to push a changeset later in order to fix this.
>> >>>
>> >>> BR
>> >>>
>> >>> Kostas
>> >>
>> >> Why do the subplot demos take so long to render?
>> >>
>> >> Is the process you're using iterative?
>> >
>> > yes, but for 2D plots it should stop after the 1st iteration step. For
>> > 3D plots it could possibly do 3-4 iterations but as shown in the
>> > screencast I had uploaded it didn't cause any performance problems
>> > e.g. with responsiveness while rotating the plot.
>> >
>> > In any case the subplot demo shouldn't noticeably longer to render, I
>> > will try to debug this case a bit in order to see why that happens.
>> >
>> >> Ben
>> >>
>> >
>> > Kostas
>> >
>> 
>> Hi Ben, I have tested the subplot demo again and I verified that the
>> iterative calculation of position terminates after a single iteration
>> step as expected. So it shouldn't add any extra computational
>> overhead. In my system the demo subplot renders quite fast, so I
>> cannot explain your observation. Could you maybe compare with previous
>> revisions of octave?
>> 
>> Concerning subplot in general, I think the layout is quite bad. Now
>> there is no labels overlapping but the subplots are not very well
>> aligned and the margin to the left and bottom of the plot window is
>> extreme. I think we should fix this in subplot.m. Matlab uses
>> activepositionproperty=position for aligning the subplots to a grid.
>> Now that we have support for get(h,'tightinset') we have the
>> possibility of doing the same as ML but we need some listeners, in
>> case titles and axes labels change.
>> 
>> Actually what I propose is to reimplement sync_positions in the
>> frontend only for subplot. The algorithm would look like:
>> 
>> 1. Get tightinsets for all subplots
>> 2. Find maximum tightinsets for all columns and rows
>> 3. Set the position property of all subplots so that they are row and
>> column aligned.
>> 
>> What do you think?
>> 
>> Kostas
>  
> In the past, but subplots showed up almost instantly.
> 
> I agree the subplot layout needs some work. The current dilemma is how to 
> determine the default inset values.
> 
> Regarding listeners, does your code not detect a change in the extents of the 
> ticklabels, axis labels, and title, and then trigger a change in the position 
> or outerposition values?
> 
> Regarding 1-3, Matlab does not do this. Look at the subplot demos, and you'll 
> see that there isn't specific number for the rows and/or columns.
> 
> My understanding has been that the outerposition and position properties are 
> set by the subplot function and that each axes behaves autonomously.
> 
> Am I wrong?
> 
> Ben

I did some experimenting with Matlab 2010b. It looks like my understanding was 
wrong.

I had a rather clear recollection of testing Matlab's behavior before. That 
will teach to to trust my memory.

I can see something is very wrong with how the outerposition is being 
calculated, but have not yet isolated the bug.

Ben