octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (subplot changes) Outerposition Patch


From: Konstantinos Poulios
Subject: Re: (subplot changes) Outerposition Patch
Date: Mon, 14 Feb 2011 16:49:39 +0100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]