Re: Distinct performance issues with Japanese only on win32 systems

2009-09-10 Thread David E Hollingsworth
My apologies for not running gtk-demo to check before offering the patch! I'm not going to be able to look into it more for a while, so reverting may be the right choice at this time. David E Hollingsworth ___ gtk-i18n-list mailing list gtk

Re: Distinct performance issues with Japanese only on win32 systems

2009-08-11 Thread David E. Hollingsworth
A few weeks ago I reported a performance issue regarding the use of Uniscribe in the win32 basic shaper. It turns out that the issue was with the use of Uniscribe's SCRIPT_CACHE. Despite the name, this value is for caching per-font-plus-size values, not per-script values. See: http://msdn.mi

Re: why there is not "pango_layout_iter_previous_line"

2009-08-07 Thread David E. Hollingsworth
=?gbk?B?zfXQ8bni?= writes: > It is used when I scroll the text. If I frequently call > "pango_layout_get_line", is the efficiency very low ? You probably want to be using pango_layout_get_line_readonly() unless you're modifying the contents. Otherwise it has to recalculate the extents each tim

Re: R: text extension problem

2009-08-05 Thread David E. Hollingsworth
"Ricchetti, Andrea" writes: > I've made some test, and I've found that the correct width and > height value are these from > > cairo_image_surface_create (CA_GetFormat(), _TextBoxWidth, _TextBoxHeight); Perhaps someone else knows what you mean. I'm not sure that I understand. It sounds like y

Re: text extension problem

2009-08-04 Thread David E. Hollingsworth
pango_layout_get_size() returns the logical (layout) size. It sounds like you want the ink size (which pixels will be touched when rendered). To get the exact ink bounds, call pango_layout_get_extents(), passing in a non-null ink_rect and a null logical_rect. pango_layout_get_pixel_extents() is

Re: Distinct performance issues with Japanese only on win32 systems

2009-07-30 Thread David E. Hollingsworth
Tor Lillqvist writes: > Hmm, is this the time it takes to process the entire document through > Pango? Or just one screenful? I,.e, is the time proportional to the > length of the document? It's proportional to the length. The real test is the C code I referred to in the previous message. The

Re: Distinct performance issues with Japanese only on win32 systems

2009-07-22 Thread David E. Hollingsworth
Hello, I have investigated this more. It does not appear to be a configuration issue, nor specific to the particular code I was using. The problem appears to be the way that Pango is using Uniscribe. If you run gedit for win32 and load a moderate-length (120kB) Japanese document, it takes seve

Distinct performance issues with Japanese only on win32 systems

2009-07-21 Thread David E. Hollingsworth
(msys/mingw) I would appreciate it if someone else would try compiling pango-win-test1.c to see if they have similar results. Thank you for any suggestions on how to proceed, David E Hollingsworth d...@curl.com -- "I've just found the silverw