GNOME Bugzilla – Bug 77182
Performance ayalysis for a lot of glyphs
Last modified: 2004-12-22 21:47:04 UTC
I tried printing for GB18030, but they needed a lot of times for outputing PS. printing about a little glyphs works fine. My test machine has PIII 500MHz and 128MB memory. this printing put in about 3 hours! bug gb18030's TrueType font is also too big. I think this printing will finish in about 2 or 3 minutes would be better. BTW I waited this printing. but gnome-print has a bug, and it output (null) into PS file.
Created attachment 7493 [details] sample file for gb18030
Created attachment 7494 [details] [review] fix patch is here
I tried printing again using this patch. it finished printing in about 3 minutes. I think it's reasonable. this patch also contains outputting (null) bug fix. this problem is my mistake in fact, but rlineto() in parseTT.c should not return with NULL.
That is a major performance improvement. It would be nice to get the patch in, but I don't know gnome-print well enough yet to say it is OK.
Indeed. applications is freezing since printing process put in 3 minutes. I think this freeze is bad. a dialog like processing should be displayed at least. otherwise the users will be afraid.
This patch looks good in general. It needs a little bit of style fixing (which i can do) and also porint to the 2.0 branch. I'll try doing it soon. Akira: - If you want to port it to the GNOME 2.0 branch it will speed things up, if not i'll do it when i get to it. thanks, Chema
Well, I don't try to test it with the same case on GNOME2, but does gnome-print for GNOME2 also have the performance issue? the handling freetype codes is different between GNOME1.4 and GNOME2. So I will be also able to test it on GNOME2. if fixing is needed, I will do that.
Yes, the code that you fixed performance is almost the same in GNOME2 the patch almost applied cleanly to gp-tt-utils.c (as oposed to parsetTT.c).
Created attachment 9184 [details] [review] Here is a patch for libgnomeprint.
I've tested it with G2. as you said, libgnomeprint also had the printing performance issue. but even if I applied a patch for 1.4, it needed about 30 minutes for the printing. so I improved a patch for the printing performance. the printing was finished about 1.5 minutes. Perhaps this fix may also help gnome-print for 1.4. I will check it with 1.4.
Luis this one renders gedit unusable in CJK locales, perhaps it should be higher severity/priority.
Havoc: yes, upping to critical I have already reviewed the patch and it looks good, the old code was doing something VERY stupid. Give me 2-3 days and I'll be in CVS.
Created attachment 9245 [details] [review] new version, fix indentation
Commited to CVS. Thanks a lot for the patch, sorry it took so long for it to make it into the CVS.
Well, 0.37 seems to not applied this patch. so the performance issue still appears on GNOME 1.4 apps.
Created attachment 13690 [details] [review] fix patch for 0.37
I'm not planning to make another release of the 1.4 branch. I would guess that you are patching gnome-print 1.4 version on redhat already? rigth?
not yet. because when we updated gnome-print to 0.37, old patch was removed so that it can't be applied cleanly, and we are waiting to be taken it by the upstream.
There's a lot of reindentation in the 0.37 version of this patch ... did you run indent over the code or something?
Owen: Akira's patch is based on the cvs commit that i did for libgnomeprint. His original patch was clean, but when i commited to the cvs, i fixed that file's indentation since that is what i've was doing with the rest of libgnomeprint during that time. It is partly my fault that his patch is like that but yes we probably want do not want to change the indentation of gnome-1-4-branch. On the other hand, I am not planning to do another release so I don't know if it makes sense for me to apply to CVS, probably not.
Created attachment 13714 [details] [review] non-indent patch
I've given some thought to this bug and I'm going to close it as WONTFIX because I will not do a new release of gnome-print 1.4. There is no point in keeping this bug opened nor commiting it to cvs.