[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (subplot changes) Outerposition Patch
From: |
Ben Abbott |
Subject: |
Re: (subplot changes) Outerposition Patch |
Date: |
Sun, 13 Feb 2011 14:49:50 -0500 |
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
- Outerposition Patch, (continued)
Re: Outerposition Patch, logari81, 2011/02/09
- Re: Outerposition Patch, David Bateman, 2011/02/10
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/10
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/10
- Re: Outerposition Patch, logari81, 2011/02/13
- Re: Outerposition Patch, Ben Abbott, 2011/02/13
- Re: (subplot changes) Outerposition Patch,
Ben Abbott <=
- Re: (subplot changes) Outerposition Patch, logari81, 2011/02/13
- Re: (subplot changes) Outerposition Patch, Ben Abbott, 2011/02/13
- Re: (subplot changes) Outerposition Patch, Konstantinos Poulios, 2011/02/14
- Re: (subplot changes) Outerposition Patch, Ben Abbott, 2011/02/15
- Re: (subplot changes) Outerposition Patch, Konstantinos Poulios, 2011/02/15
- Re: (subplot changes) Outerposition Patch, bpabbott, 2011/02/15
- Re: (subplot changes) Outerposition Patch, Konstantinos Poulios, 2011/02/15
- Re: (subplot changes) Outerposition Patch, bpabbott, 2011/02/15
Re: (subplot changes) Outerposition Patch, Konstantinos Poulios, 2011/02/15
Re: (subplot changes) Outerposition Patch, bpabbott, 2011/02/15