Re: (subplot changes) Outerposition Patch

[Ben Abbott]

On Feb 13, 2011, at 2:03 PM, Ben Abbott wrote:

> On Feb 13, 2011, at 12:05 PM, logari81 wrote:
> 
>> On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
>>> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios
>>> <address@hidden> wrote:
>>>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden> wrote:
>>>>> 
>>>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a écrit :
>>>>> 
>>>>>>> 
>>>>>> thank you for this information.
>>>>>> 
>>>>>> It seems that the previously attached patch causes problems only with
>>>>>> legends. However, in order to treat legends correctly I need to
>>>>>> understand their logic. How do legends exploit the outerposition and
>>>>>> position properties? Is anyone familiar with legend.m to give me a short
>>>>>> introduction?
>>>>>> 
>>>>>> Best regards
>>>>>> 
>>>>> You shouldn't try to understand the logic of legend's use of the position 
>>>>> and outerposition properties. It's just a hack that worked with the 
>>>>> existing behavior. If your patch doesn't work well with legend it is 
>>>>> probably legend that needs to be fixed
>>>>> 
>>>>> D.
>>>> 
>>>> The attached patch replaces the previous one and implements the
>>>> calculation of both position and outerposition depending on the value
>>>> of activepositionproperty.
>>>> 
>>>> It is not very well tested yet, so there will probably be some issues,
>>>> e.g. legends will not work, but it brings a feature that maybe is
>>>> awesome. It is something that Matlab cannot do and maybe you like it.
>>>> See the following video:
>>>> 
>>>> http://ubuntuone.com/p/cYM/
>>>> 
>>>> The position property is calculated dynamically while you rotate the
>>>> view, so that all labels fit in outerposition. I think it works quite
>>>> well in order to keep it. What do you think?
>>>> 
>>>> As this operation involves certain computational overhead, it would be
>>>> interesting to get some tests on older machines. Unfortunately all
>>>> pc's that I have access to, are too fast.
>>>> 
>>>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for the fltk 
>>>> toolkit.
>>>> 
>>>> Finally, if we adopt the attached patch we have to adapt legend.m also.
>>>> 
>>>> BR
>>>> 
>>>> Kostas
>>> 
>>> After some more testing and fixes I think the patch is quite mature in
>>> the form you find in the attachment. I think it could be checked in.
>>> 
>> I have just checked in this changeset along with some further
>> fixes/improvements. Now, I would like to provide some additional
>> information and ask for some help with regard to the open issues that I
>> had listed.
>> 
>>> There are still some general issues with fltk that I will try to sum up:
>>> 
>>> 1. In some demo plots axes labels seem to be too close to the axes
>>> (e.g. demo legend 9). Probably in some of the previous changes there
>>> is something that I have overseen.
>>> 
>> Actually after testing older revisions of octave I realized that the
>> problem is not new. The reason that I hadn't noticed it before is
>> because the problem appears only in the print output and not in the plot
>> window. It seems that gl-render and gl2ps position strings differently
>> considering either the bottom line or the baseline of the string
>> respectively. It is not difficult to fix, we just have to decide which
>> of gl-render and gl2ps are we going to fix in order to make both
>> consistent.
> 
> I suspect the culprit may be that gl2ps requires assumes that the DPI is 72.
> 
> Perhaps the font position is correct, but the fontsize is off by 100/72? But 
> is that due to a bug in gl2ps or a problem with Octave's positioning of text 
> objects?
> 
>>> 2. Legends for barplots don't show colors (this is an old problem).
>>> 
>>> 3. Some small y axes interference for plotyy (also not new).
>>> 
>>> 4. Now there is no labels-titles interference in demo subplot 1, so
>>> there is no need for extra space between the subplots, we can reduce a
>>> bit the padding (someone which is familiar with subplot.m I suppose).
>>> 
>> Waiting for someone familiar with subplot.m
> 
> I'll take a look.

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 ..

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?

If that is the case, I think subplot.m should be rewritten and let the c++ 
synchronization of position / outerposition do its job.

Perhaps subplot() should only specify the outerposition, and let the c++ 
synchronization take care of the rest?

Ben

changeset.patch
Description: Binary data