[Octave-bug-tracker] [bug #43907] OpenGL render code called even when gnuplot is graphics_toolkit

[Rik]

URL:
  <http://savannah.gnu.org/bugs/?43907>

                 Summary: OpenGL render code called even when gnuplot is
graphics_toolkit
                 Project: GNU Octave
            Submitted by: rik5
            Submitted on: Tue 30 Dec 2014 02:41:00 PM PST
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

The render code for OpenGL is being called, despite the fact that a different
toolkit is set up.  This produces an annoying message and is certainly a
performance hit if we execute both sets of code and then keep only one.

Sample code:


graphics_toolkit gnuplot
text (0.5, 0.5, '\0', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12


I ran Octave under gdb and set a breakpoint before it got to print the warning
message.  What you can see is that the text.m file calls __go_text__ which
then starts to initialize a graphics object by setting various properties. 
When the fontname is set the render code gets processed, instead of just
setting the field to the desired value.


#0  ft_render::process_character (this=0x10f9fd8, code=8709, previous=0)
    at corefcn/txt-eng-ft.cc:515
#1  0x00007ffff7727ade in ft_render::visit (this=0x10f9fd8, e=...) at
corefcn/txt-eng-ft.cc:810
#2  0x00007ffff74410ee in text_element_symbol::accept (this=0x159ee50, p=...)
    at corefcn/txt-eng.h:359
#3  0x00007ffff77295c3 in text_processor::visit (this=0x10f9fd8, e=...)
    at corefcn/txt-eng.h:325
#4  0x00007ffff7726d4b in ft_render::visit (this=0x10f9fd8, e=...) at
corefcn/txt-eng-ft.cc:682
#5  0x00007ffff744111e in text_element_list::accept (this=0x158cd50, p=...)
    at corefcn/txt-eng.h:360
#6  0x00007ffff7727e22 in ft_render::render (this=0x10f9fd8, elt=0x158cd50,
box=..., 
    rotation=0) at corefcn/txt-eng-ft.cc:855
#7  0x00007ffff7728c52 in ft_render::text_to_pixels (this=0x10f9fd8, txt=...,
pixels_=..., 
    box=..., _halign=0, valign=1, rotation=0, interpreter=...) at
corefcn/txt-eng-ft.cc:986
#8  0x00007ffff7546740 in text::properties::update_text_extent
(this=0x10f81c0)
    at corefcn/graphics.cc:7909
#9  0x00007ffff757abfa in text::properties::update_fontname (this=0x10f81c0)
    at corefcn/graphics.h:8327
#10 0x00007ffff75796ea in text::properties::set_fontname (this=0x10f81c0,
val=...)
    at corefcn/graphics.h:7974
#11 0x00007ffff74bc934 in text::properties::set (this=0x10f81c0,
pname_arg=..., val=...)
    at corefcn/graphics-props.cc:3259
#12 0x00007ffff7566bd1 in base_graphics_object::set (this=0x10f81b0,
pname=..., pval=...)
    at corefcn/graphics.h:2976
#13 0x00007ffff745a5c2 in graphics_object::set_value_or_default
(this=0x7fffffffa850, 
    name=..., val=...) at corefcn/graphics.cc:2316
#14 0x00007ffff7459f35 in graphics_object::set (this=0x7fffffffa850,
args=...)
    at corefcn/graphics.cc:2083
#15 0x00007ffff745aeba in xset (h=..., args=...) at corefcn/graphics.cc:2486
#16 0x00007ffff7554102 in make_graphics_object (go_name=...,
integer_figure_handle=false, 
#17 0x00007ffff7555495 in F__go_text__ (args=...) at
corefcn/graphics.cc:10319
#18 0x00007ffff718d0b3 in octave_builtin::do_multi_index_op (this=0x6e4ca0,
nargout=1, 
    args=..., lvalue_list=0x0) at octave-value/ov-builtin.cc:132
#19 0x00007ffff718cd8c in octave_builtin::subsref (this=0x6e4ca0, type=...,
idx=..., 
    nargout=1, lvalue_list=0x0) at octave-value/ov-builtin.cc:65
#20 0x00007ffff718cc7a in octave_builtin::subsref (this=0x6e4ca0, type=...,
idx=..., nargout=1)
    at octave-value/ov-builtin.cc:47
#21 0x00007ffff718dbd9 in octave_builtin::subsref (this=0x6e4ca0, type=...,
idx=...)
    at octave-value/ov-builtin.h:62
#22 0x00007ffff726fffb in octave_value::subsref (this=0x7fffffffb1b0,
type=..., idx=..., 
    nargout=1) at octave-value/ov.cc:1301
#23 0x00007ffff72700f6 in octave_value::subsref (this=0x7fffffffb1b0,
type=..., idx=..., 
    nargout=1, lvalue_list=0x0) at octave-value/ov.cc:1314
#24 0x00007ffff72df02e in tree_index_expression::rvalue (this=0xcf33e0,
nargout=1, 
    lvalue_list=0x0) at parse-tree/pt-idx.cc:437
#25 0x00007ffff72de5d3 in tree_index_expression::rvalue (this=0xcf33e0,
nargout=1)
    at parse-tree/pt-idx.cc:284
#26 0x00007ffff72df458 in tree_index_expression::rvalue1 (this=0xcf33e0,
nargout=1)
    at parse-tree/pt-idx.cc:466
#27 0x00007ffff72c98d0 in tree_simple_assignment::rvalue1 (this=0xcf36f0)
    at parse-tree/pt-assign.cc:85
#28 0x00007ffff72d7df8 in tree_evaluator::visit_statement
(this=0x7ffff7dd4478, stmt=...)
    at parse-tree/pt-eval.cc:744
#29 0x00007ffff72f8fbc in tree_statement::accept (this=0xcf3730, tw=...)
    at parse-tree/pt-stmt.cc:178
#30 0x00007ffff72d8064 in tree_evaluator::visit_statement_list
(this=0x7ffff7dd4478, lst=...)
    at parse-tree/pt-eval.cc:794
#31 0x00007ffff72f95dc in tree_statement_list::accept (this=0xcf1460, tw=...)
    at parse-tree/pt-stmt.cc:291


The backtrace continues on but it is uninteresting.  The good stuff starts at
#17.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43907>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/