[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: units updater for figures is broken when using fltk
From: |
Ben Abbott |
Subject: |
Re: units updater for figures is broken when using fltk |
Date: |
Sat, 04 Feb 2012 19:35:42 -0500 |
On Feb 4, 2012, at 5:09 PM, Michael Goffioul wrote:
> On Sat, Feb 4, 2012 at 9:57 PM, Ben Abbott <address@hidden> wrote:
>
>> On Feb 4, 2012, at 4:42 PM, Michael Goffioul wrote:
>>
>>> On Sat, Feb 4, 2012 at 9:32 PM, Ben Abbott <address@hidden> wrote:
>>>>
>>>> On Feb 4, 2012, at 2:46 PM, Ben Abbott wrote:
>>>>
>>>>> Running the script below ...
>>>>>
>>>>> close all
>>>>> graphics_toolkit fltk
>>>>> figure
>>>>> position = get (gcf, "position")
>>>>> set (gcf, "units", "normalized")
>>>>> position_pre_drawnow = get (gcf, "position")
>>>>> drawnow
>>>>> position_post_drawnow = get (gcf, "position")
>>>>>
>>>>> ... produces the result ...
>>>>>
>>>>> position =
>>>>>
>>>>> 300 200 560 420
>>>>>
>>>>> position_pre_drawnow =
>>>>>
>>>>> 0.17798 0.19358 0.33333 0.40856
>>>>>
>>>>> position_post_drawnow =
>>>>>
>>>>> 0 44 1 0
>>>>>
>>>>> I have no idea what is happing here, and my debugging skills for c++ are
>>>>> embarrassingly poor. Does anyone have any insight ?
>>>>>
>>>>> There's a bug report. Link below.
>>>>>
>>>>> https://savannah.gnu.org/bugs/index.php?35430
>>>>>
>>>>> Ben
>>>>
>>>> I gave up on myself a bit too early.
>>>>
>>>> I've attached a changeset that fixes the problem for me.
>>>
>>> That (setting units to "pixels" during redraw) should not be needed.
>>> Looks to me like a workaround for the real problem. For instance, a
>>> figure redraw can happen outside the drawnow function.
>>>
>>> Michael.
>>
>> Ouch ! You are obviously correct. If I eliminate the drawnow(), the figure
>> shrinks to [1x0] size in the UL of my screen.
>>
>> As this isn't needed for gnpulot, should this be handled in __init_flkt__
>> (__fltk_redraw__).
>>
>> Or is there somewhere in graphics.cc that bottle-necks all redraws ?
>
> No. A redraw can be triggered in the backend itself due to some user
> action. Anyway, temporarily changing the units is not a solution. This
> is just a hack that hides the real problem, which I think is the
> following: in __init_fltk__.cc, plot_window::draw() maps figure's
> position property to the FLTK window location (which is in pixels).
> This is only valid when the figure's units is in pixels [1]. The
> proper implementation is to use the
> figure::properties::get_boundingbox() method to obtain the figure
> location in pixels.
>
> Michael.
>
> [1]: I'm also wondering how that piece of code is handling the fact
> that in Matlab world (0,0) corresponds to the bottom-left corner of
> the screen, not the top-left corner; but that's another story.
This diff below worked for me, but I liked your suggestion of using the
get_boundingbox better.
----------------------
diff --git a/src/DLD-FUNCTIONS/__init_fltk__.cc
b/src/DLD-FUNCTIONS/__init_fltk__.cc
--- a/src/DLD-FUNCTIONS/__init_fltk__.cc
+++ b/src/DLD-FUNCTIONS/__init_fltk__.cc
@@ -1173,7 +1173,10 @@
void draw (void)
{
+ octave_value funits = fp.get_units ();
+ fp.set_units (octave_value ("pixels"));
Matrix pos = fp.get_position ().matrix_value ();
+ fp.set_units (funits);
Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);
return Fl_Window::draw ();
----------------------
Unfortunately, it looks to me as if get_boundingbox returns the wrong result.
I tried the change below ...
----------------------
--- a/src/DLD-FUNCTIONS/__init_fltk__.cc
+++ b/src/DLD-FUNCTIONS/__init_fltk__.cc
@@ -1173,7 +1173,7 @@
void draw (void)
{
- Matrix pos = fp.get_position ().matrix_value ();
+ Matrix pos = fp.get_boundingbox (true);
Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);
return Fl_Window::draw ();
----------------------
The result was what appeared to be an infinite loop, that produced a very large
figure that rendered mostly to the right of my screen.
Am I missing something, or is the get_boundingbox result due to your comment
regarding Matlab world above [1].
Ben
- sombrero doesn't show (fltk), Muhali, 2012/02/01
- Re: sombrero doesn't show (fltk), Ben Abbott, 2012/02/01
- units updater for figures is broken when using fltk, Ben Abbott, 2012/02/04
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/04
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/04
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/04
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/04
- Re: units updater for figures is broken when using fltk,
Ben Abbott <=
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/05
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/05
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/07
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/07
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/07
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/10
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/11
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/11
- Re: units updater for figures is broken when using fltk, Michael Goffioul, 2012/02/11
- Re: units updater for figures is broken when using fltk, Ben Abbott, 2012/02/11