octave-maintainers
[Top][All Lists]
Advanced

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

Re: (subplot changes) Outerposition Patch


From: bpabbott
Subject: Re: (subplot changes) Outerposition Patch
Date: Tue, 15 Feb 2011 17:40:36 +0000 (GMT)

On Feb 15, 2011, at 12:03 PM, Konstantinos Poulios <address@hidden> wrote:

On Tue, Feb 15, 2011 at 5:32 PM, bpabbott <address@hidden> wrote:
> On Feb 15, 2011, at 09:12 AM, 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
> eg. 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.
>
>
> I'll wait for you to find the reason for the slow down. Currently I see ...
>  tic; demo ('subplot', 1); toc
> subplot example 1:
>  clf
>  r = 3;
>  c = 3;
>  fmt = {'horizontalalignment', 'center', 'verticalalignment', 'middle'};
>  for n = 1:(r*c)
>    subplot (r, c, n)
>    xlabel (sprintf ("xlabel #%d", n))
>    ylabel (sprintf ("ylabel #%d", n))
>    title (sprintf ("title #%d", n))
>    text (0.5, 0.5, sprintf('subplot(%d,%d,%d)', r, c, n), fmt{:})
>    axis ([0 1 0 1])
>  endfor
>  subplot (r, c, 1:3)
>  xlabel (sprintf ("xlabel #%d:%d", 1, 3))
>  ylabel (sprintf ("ylabel #%d:%d", 1, 3))
>  title (sprintf ("title #%d:%d", 1, 3))
>  text (0.5, 0.5, sprintf('subplot(%d,%d,%d:%d)', r, c, 1, 3), fmt{:})
>  axis ([0 1 0 1])
> Elapsed time is 10 seconds.
> This makes modifying subplot very frustrating.
> Ben
>

We have crossed mails, on my system it takes about 1 sec. Are you
testing this on a mac or Ubuntu in VM?

Have you tried a fresh build? I have just recompiled everything from
scratch with the most recent hg changeset.

Kostas
 
I tried the test on two different Macs. They each give about 10 secs. This delay is present for both FLTK and Gnuplot.

Under Ubuntu (VirtualBox) I get about 2.8 secs.

Ben


reply via email to

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