Hello,
I have noticed significant performance issues with pango when
displaying Japanese text on win32 systems. Thus far, I've assumed
that this was a configuration issue, but I've encountered the problem
using the stock gtk+ win32 binaries on what I believe is a standard
msys/mingw setup on bot
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
> If you run gedit for win32 and load a moderate-length (120kB) Japanese
> document, it takes several seconds, whereas an English equivalent
> document is essentially instantaneous.
Hmm, is this the time it takes to process the entire document through
Pango? Or just one screenful? I,.e, is the tim
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
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
> Since shaping occurs on runs containing a single font, we only need
> one SCRIPT_CACHE in uniscribe_shape. I'm including a patch below that
> does this. With the patch applied, the time for one of my tests went
> from 20s to .3s.
Wow! Thank you very much for investigating. Will apply the patch
> Wow! Thank you very much for investigating. Will apply the patch.
I applied the patch already in mid-August to the stable and
development branches, but unfortunately it turns out that after the
patch, shaping of complex scripts is quite broken. Sorry that I didn't
notice earlier. The Arabic in g
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-i18n-
Hi,
It seems Pango uses the Uniscribe script cache in a sub optimal way.
Pango always create new script caches and throws them away in each
call to uniscribe_shape.
But in the Uniscribe docs it does not say that the cache needs to be
cleared between ScriptItemize calls.
We did some experiments and
Hmm, Fredrik, is this related to the earlier thread from half a year
ago or not? Is this a new and improved solution to the same problem?
You don't mention the earlier patch (which was reverted because it
broke Arabic shaping, for instance) at all...?
--tml
I just saw that I mentioned the wrong Pango version, It's actually a
patch for Pango 1.26.2. not 1.16.2.
I would like to thank Dave E Hollingsworth for finding and working on
this issue in the first place.
On Thu, Apr 8, 2010 at 8:17 PM, Fredrik Corneliusson
wrote:
> Hi,
> It seems Pango uses th
> Yes this is related to Davids patch. It differs from that patch in
> that it keeps the separate caches for scripts and only makes them
> static.
Ah, yes. I replied in a hurry without actually having even looked at
your patch, sigh... It is quite minimal, I love that!
> Reading the uniscribe doc
I am not sure I would trust basing the hash on the
pango_font_description_hash() value. I would prefer to use the
specific HFONT for each run of glyphs from one physical font. I'm too
lazy to look up right now how in the basic-win32.c code one can find
that information...
--tml
___
Hi Tor,
I think its "pango_win32_get_hfont" in pangowin32.c.
static HFONT pango_win32_get_hfont (PangoFont *font);
I removed the static and defined it as external to be able to call it
from basic-win32.c.
Unfortunately calling the "pango_win32_get_hfont" in
"itemize_shape_and_place" function seems
Hi Tor,
I managed to create a modified version of the "pango_win32_get_hfont"
function called "pango_win32_peek_hfont" that do not break the
rendering.
Patch now uses the hfont & script for the script cache mapping.
Regards,
Fredrik
On Mon, Apr 12, 2010 at 4:59 PM, Fredrik Corneliusson
wrote:
>
FYI,
This issue is now reported in bugzilla (bug number 621869).
https://bugzilla.gnome.org/show_bug.cgi?id=621869
Patch attached to ticket.
Regards,
Fredrik
On Sun, Apr 18, 2010 at 6:03 PM, Fredrik Corneliusson
wrote:
> Hi Tor,
> I managed to create a modified version of the "pango_win32_get_
> This issue is now reported in bugzilla (bug number 621869).
> https://bugzilla.gnome.org/show_bug.cgi?id=621869
Yes, thanks. Will test shortly and apply, thanks!
--tml
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailma
17 matches
Mail list logo
