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

 
 

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

Submitted by:  None
Submitted on:  Sun 20 Feb 2011 11:19:09 PM UTC  
 
Category: NoneSeverity: 4 - Important
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
Fri 08 Apr 2011 08:14:00 PM UTC, comment #6:

Thank you, I have put these in git.

Richard Shann <rshann>
Project 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

(file #23147, file #23148)

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>
Project 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.

(file #23085, file #23086)

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>
Project 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 File(s):
   
   
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
  • -unavailable- added by rshann (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 11 Feb 2012 02:45:07 PM UTCrshannStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Fri 08 Apr 2011 08:14:00 PM UTCrshannSummaryBreve and longa cause inordinately high cpu usage=>.svg graphics derived from font cause inordinately high cpu usage
    Fri 08 Apr 2011 07:35:18 PM UTCNoneAttached File-=>Added BreveRest.png, #23147
      Attached File-=>Added LongaRest.png, #23148
    Sun 03 Apr 2011 12:54:45 AM UTCNoneAttached File-=>Added Breve.png, #23085
      Attached File-=>Added Longa.png, #23086
    Sat 26 Mar 2011 08:27:11 AM UTCrshannSeverity3 - 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.1-cleanup1