help-octave
[Top][All Lists]
Advanced

[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





reply via email to

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