bugDenemo - Bugs: bug #32550, .svg graphics derived from font...

 
 

bug #32550: .svg graphics derived from font cause inordinately high cpu usage

Submitter:  None
Submitted:  Sun 20 Feb 2011 11:19:09 PM UTC
   
 
Category:  None Severity:  4 - Important
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Feb 2012 02:45:07 PM UTC, comment #7: 

Due to very large size, no longer used.

Richard Shann <rshann>
Group administrator
Fri 08 Apr 2011 08:14:00 PM UTC, comment #6: 

Thank you, I have put these in git.

Richard Shann <rshann>
Group administrator
Fri 08 Apr 2011 07:35:18 PM UTC, comment #5: 

If you want .png's for the rests, here they are.
Looks like a y offset of -10 for the longa and a -15 for the breve works well for positioning them.
-Dan


Anonymous
Thu 07 Apr 2011 09:04:31 AM UTC, comment #4: 

Apparently, just changing the "width" and "height" fields and then dividing each number that appears in the <\path ...> field by 10 scales...
I don't think this is true for all the types of path fields unfortunately.
I think if we can reduce them it will work - the cpu usage should only be proportional to the number on visible in the displayed portion of the score, not the total number in the score. This is the same as for .png graphics.

Here are a couple of .png 's ....
I have put these in (renamed notehead_M?neomensural.png) and they do the trick. We don't have the rests.
This workaround actually yields better zooming (which is what .svgs are for in part) because of the cairo bug.

Richard Shann <rshann>
Group administrator
Sun 03 Apr 2011 02:46:08 AM UTC, comment #3: 

An idea on a possible workaround.  Would editing the svg files to a size of 100x100 partially resolve this?  Apparently, just changing the "width" and "height" fields and then dividing each number that appears in the <\path ...> field by 10 scales the image down by a factor of 1/10.  This could be done with a script applied to all .svg files necessary.  Or if only a few are needed it could be done by hand.
The remaining problem would be the fact that I observed that the cpu usage increased with the number of breves/longas inserted, so even though this could cut the memory usage by 1/100 it would still climb as you added more of these notes.
Just an idea.
-DW

Anonymous
Sun 03 Apr 2011 12:54:45 AM UTC, comment #2: 

Here are a couple of .png 's that should work for a workaround.
Do watch out for the vertical offset of these--it may require tweaking to make sure when the user enters a C, it looks like a C on the score view.
Obviously it looks bad when you zoom in, but I guess that will be fixed when the cairo problem is solved.
-Dan W.


Anonymous
Sat 26 Mar 2011 08:27:11 AM UTC, comment #1: 

This is not specific to windows. It is probably due to the .svg images being 1000x1000 in "size"
We need cairo expertise to solve this. The code is drawing by  calling
cairo_mask(cr, pattern);
on a pattern derived from a 1000x1000 SVG image stored in a file name.svg. The code to generate the pattern is this:

    gchar *filename = g_strconcat(name, ".svg", NULL);

    gfloat thescale=0.04, offx=500.0, offy=500.0;

    g_print("Scale %f and offset (%f, %f) are chosen to match the set of .svgs extracted from the emmenthaler font\n", thescale, offx, offy);
    RsvgHandle *handle = rsvg_handle_new_from_file(filename, &error);
    g_free(filename);
    if(handle==NULL) {
      if(error)
g_warning("Could not open %s error %s\n", basename, error->message);
      else
g_warning("Opening %s, Bug in librsvg:rsvg handle null but no error message", basename);
      return FALSE;
    }
    RsvgDimensionData thesize;
    rsvg_handle_get_dimensions(handle, &thesize);
   
    g_print("size %d x %d", thesize.width, thesize.height);

    cairo_surface_t surface =   (cairo_surface_t )cairo_svg_surface_create_for_stream (NULL, NULL, (gdouble)thesize.width,  (gdouble)thesize.height);
    cairo_t *cr = cairo_create(surface);
    cairo_translate(cr, offx, offy);
    cairo_scale(cr, thescale, -thescale);
    g_print("scaled %f %f %f\n", thescale, offx, offy);

    rsvg_handle_render_cairo(handle, cr);
    rsvg_handle_close(handle, NULL);
    g_object_unref(handle);
    cairo_pattern_t *pattern = cairo_pattern_create_for_surface (surface);
    cairo_pattern_reference(pattern);
    cairo_destroy(cr);

Richard Shann <rshann>
Group administrator
Sun 20 Feb 2011 11:19:09 PM UTC, original submission:  

This is the carry-over from the other bug report.  (The other stuff was fixed--thanks a lot.)

Change the time signature to 16/4, and fill up about 16 bars with breve and longa.

The cpu usage jumps up to about 30% when denemo is idling.  (normal denemo usage is at 1%)  The ram usage jumps around erratically (but NOT showing a long-term upward tendency).  On my machine, from about 11,500K to 12,500K, every second or so it appears as a new apparently random value in that range.

-Dan W.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #23147:  BreveRest.png added by None (187B - image/png)
file #23148:  LongaRest.png added by None (189B - image/png)
file #23085:  Breve.png added by None (222B - image/png)
file #23086:  Longa.png added by None (232B - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-11 rshann StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2011-04-08 rshann SummaryBreve and longa cause inordinately high cpu usage .svg graphics derived from font cause inordinately high cpu usage
    2011-04-08 None Attached File- Added BreveRest.png, #23147
        Attached File- Added LongaRest.png, #23148
    2011-04-03 None Attached File- Added Breve.png, #23085
        Attached File- Added Longa.png, #23086
    2011-03-26 rshann Severity3 - Normal 4 - Important
        StatusNone Confirmed
        SummaryBreve and longa cause inordinately high cpu usage on windows xp Breve and longa cause inordinately high cpu usage

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code