Mike Solomon m...@mikesolomon.org writes:
On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote:
On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon m...@mikesolomon.org
wrote:
On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote:
Most of the contortions seem
On Dec 15, 2013, at 10:46 AM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
The layout engine could use get_property_data() freely, but before it
has set line-breaks the layout engine would refrain from calling any
callback functions directly. Instead of
Mike Solomon m...@mikesolomon.org writes:
On Dec 15, 2013, at 10:46 AM, David Kastrup d...@gnu.org wrote:
[...]
I like the idea of their being a single property that is honed in on
with successive estimates until we get the perfect value. This is how
I do a Sudoku - I pencil the guesses in
raw/final would be shorter than pure/unpure.
I like that. At least for me this is easier to understand from a
conceptual point of view.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Blasphemy!
Then LilyPond is a blasphemous piece of software...that has typeset
thousands of pieces of liturgical music…
Well, Moses got his ten commands typeset on stone plates. It probably
takes some time until the heavenly software gets updated to use more
recent releases.
Werner
Werner LEMBERG w...@gnu.org writes:
Blasphemy!
Then LilyPond is a blasphemous piece of software...that has typeset
thousands of pieces of liturgical music…
Well, Moses got his ten commands typeset on stone plates.
He got only the first version typeset for him. He destroyed them. The
Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM
raw/final would be shorter than pure/unpure.
I like that. At least for me this is easier to understand from a
conceptual point of view.
pencil/ink.
___
lilypond-devel mailing list
Trevor Daniels t.dani...@treda.co.uk writes:
Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM
raw/final would be shorter than pure/unpure.
I like that. At least for me this is easier to understand from a
conceptual point of view.
pencil/ink.
More like pencil/stencil, and then we
On Dec 15, 2013, at 11:22 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM
raw/final would be shorter than pure/unpure.
I like that. At least for me this is easier to understand from a
conceptual point of view.
pencil/ink.
All
Keith OHara wrote:
the pure-estimate and unpure-final versions of a function
[...]
The word 'pure' might have too much a connotation as 'good'. Maybe we
should rename 'pure' -
'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
Oh, so *that's* what
Devon Schudy dsch...@gmail.com writes:
Keith OHara wrote:
the pure-estimate and unpure-final versions of a function
[...]
The word 'pure' might have too much a connotation as 'good'. Maybe we
should rename 'pure' -
On Sat, 14 Dec 2013 23:57:20 -0800, Mike Solomon m...@mikesolomon.org wrote:
On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote:
The most transparent reorganization might be to have all properties that can
hold data use the usual callback mechanism: where the callback
Keith OHara k-ohara5...@oco.net writes:
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote:
That does not make sense. If you want call-once behavior, you can just
use a callback.
At the moment, the decision on whether to preserve the callback
pointer in the grob
On Dec 14, 2013, at 9:21 AM, Keith OHara k-ohara5...@oco.net wrote:
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote:
That does not make sense. If you want call-once behavior, you can just
use a callback.
At the moment, the decision on whether to preserve the callback
On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote:
That does not make sense. If you want call-once behavior, you can just
use a callback.
At the moment, the
On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon m...@mikesolomon.org wrote:
On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote:
Most of the contortions seem focused about when or when not and how to
pass begin/end columns. It would seem to make sense to turn them into
dynamic
On Sat, 14 Dec 2013 14:58:52 -0800, Keith OHara k-ohara5...@oco.net wrote:
Several considered line-breaks might have the same 'start' and 'end' around the
hairpin, but the upper-level axis-group structure caches results for each
start/end pair so just one skyline is generated for each
On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote:
On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon m...@mikesolomon.org wrote:
On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote:
Most of the contortions seem focused about when or when not and how to
pass
Open_type_font:: and Pango_font::name_to_index() each call
FT_Get_Name_Index(). Inserting print statements to trace those calls
I find that FT_Get_Name_Index is called:
7 times for each character in a Tempo
5 times for each character in a Text Script
...
1 time for each notehead
5 times
Werner LEMBERG w...@gnu.org writes:
Open_type_font:: and Pango_font::name_to_index() each call
FT_Get_Name_Index(). Inserting print statements to trace those calls
I find that FT_Get_Name_Index is called:
7 times for each character in a Tempo
5 times for each character in a Text Script
...
I will check whether I can improve that in FreeType.
Is there a reason this would have such a significantly different
impact in Windows?
No. It's exactly the same code on both platforms. However, for
lilypond, even a single-element cache would help, see attached
quick'n'dirty patch (for
On Thu, 12 Dec 2013 23:07:19 -0800, Keith OHara k-ohara5...@oco.net wrote:
I am happy to say that I was wrong here.
Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index().
Inserting print statements to trace those calls I find that FT_Get_Name_Index
is called:
7
On Fri, 13 Dec 2013 01:38:23 -0800, Werner LEMBERG w...@gnu.org wrote:
I will check whether I can improve that in FreeType.
Is there a reason this would have such a significantly different
impact in Windows?
No. It's exactly the same code on both platforms. However, for
lilypond, even a
I do see how sfnt_get_name_index() does a linear search through the
font to find a matching name. Much better if LilyPond could look up
text characters by their Unicode encoding.
Well, there are historic reasons for that. On the other hand, I think
that for lilypond, which often provides
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote:
Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index().
Inserting print statements to trace those calls I find that FT_Get_Name_Index
is called:
7 times for each character in a Tempo
The layers of
Keith OHara k-ohara5...@oco.net writes:
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote:
Open_type_font:: and Pango_font::name_to_index() each call
FT_Get_Name_Index(). Inserting print statements to trace those
calls I find that FT_Get_Name_Index is called:
7 times for
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote:
That does not make sense. If you want call-once behavior, you can just
use a callback.
At the moment, the decision on whether to preserve the callback pointer in the
grob property, or fill the property with the returned
Werner LEMBERG w...@gnu.org writes:
One extra lookup per glyph might be enough to explain the difference.
We need to look up the glyph to get a skyline, but maybe could cache
its index into the font in the stencil.
That does not sound very useful since we still would do the lookup
once per
On Dec 12, 2013, at 10:43 AM, David Kastrup d...@gnu.org wrote:
Werner LEMBERG w...@gnu.org writes:
One extra lookup per glyph might be enough to explain the difference.
We need to look up the glyph to get a skyline, but maybe could cache
its index into the font in the stencil.
That does
Caching of frequently accessed information if that information is
expensive to access.
*That* I have understood :-) Please give more information, in
particular, which calls appear to be expensive.
Nope. FreeType uses exactly the same code on both platforms,
Unlikely as it is talking to
On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara k-ohara5...@oco.net wrote:
After a brief look at the code, it looked like for each glyph being laid out
there is one extra call of Open_type_font:: or Pango_font::name_to_index(),
which is the function called by find_by_name() that caused the
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote:
On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara k-ohara5...@oco.net wrote:
After a brief look at the code, it looked like for each glyph being laid out
there is one extra call of Open_type_font:: or
Keith OHara k-ohara5...@oco.net writes:
On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
The last time we had a doubling of time required on Windows relative
to Linux, issue 1926, it was repeated calls to find_by_name() that go
2013/12/10 Phil Holmes m...@philholmes.net
- Original Message - From: Werner LEMBERG w...@gnu.org
To: m...@mikesolomon.org
Cc: k-ohara5...@oco.net; d...@gnu.org; lilypond-devel@gnu.org
Sent: Tuesday, December 10, 2013 9:43 AM
Subject: Re: anyone notice speed of 2.17.95 on Windows
One extra lookup per glyph might be enough to explain the difference.
We need to look up the glyph to get a skyline, but maybe could cache
its index into the font in the stencil.
That does not sound very useful since we still would do the lookup
once per stencil rather than once per m and
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
I timed one big score, Movement 1 of
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793
2.16.2 2.17.95
WinXP 2m 30s 5m 10s
Fedora 1m 50s 1m 50s
Have you
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote:
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
I timed one big score, Movement 1 of
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793
Keith OHara wrote Tuesday, December 10, 2013 8:36 AM
Most of the increase in time to set this score happened between 2.17.0 and .1
2.16.2 2m 30s
2.17.0 2m 28s
2.17.1 4m 06s
so it is probably the issue 2148 patch, use of outlines instead of boxes for
layout.
I did speed-test that
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote:
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
I timed one big score, Movement 1 of
On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote:
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
\faster-but-uglier
\a-lot-faster-but-a-lot-uglier
\ridiculously-fast-and-heinously-ugly
:-) With some serious names, this could be quite useful.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote:
I did speed-test that patch, but under Linux. Maybe the system
calls
- Original Message -
From: Werner LEMBERG w...@gnu.org
To: m...@mikesolomon.org
Cc: k-ohara5...@oco.net; d...@gnu.org; lilypond-devel@gnu.org
Sent: Tuesday, December 10, 2013 9:43 AM
Subject: Re: anyone notice speed of 2.17.95 on Windows ?
\faster-but-uglier
\a-lot-faster-but-a-lot
On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote:
I
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote:
Nope. In this case, the answer is to cache frequently accessed
information instead of requesting it again and again.
We don't want to give people a choice between different ways in
On Dec 10, 2013, at 12:18 PM, David Kastrup d...@gnu.org wrote:
Mike Solomon m...@mikesolomon.org writes:
On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote:
Nope. In this case, the answer is to cache frequently accessed
information instead of requesting it again and again.
On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote:
When I benchmarked with and without
skylines, I found there was only a noticeable difference with a lot of
markup or similar: normal music had almost no effect. As a result, I
concluded with skylining was the correct
On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara k-ohara5...@oco.net wrote:
On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote:
When I benchmarked with and without
skylines, I found there was only a noticeable difference with a lot of
markup or similar: normal music had
Keith OHara k-ohara5...@oco.net writes:
On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara k-ohara5...@oco.net wrote:
On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote:
When I benchmarked with and without
skylines, I found there was only a noticeable difference with a
On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup d...@gnu.org wrote:
Keith OHara k-ohara5...@oco.net writes:
The last time we had a doubling of time required on Windows relative
to Linux, issue 1926, it was repeated calls to find_by_name() that go
through Pango to the font server.
Here the
Keith OHara k-ohara5...@oco.net writes:
LilyPond has always been a slower on Windows than under Linux, but I get
worried if it is more than twice as slow. I would think the operating
systems affect speed mostly through 1) the font server, 2) memory allocation,
and 3) the Guile
LilyPond has always been a slower on Windows than under Linux, but I get
worried if it is more than twice as slow. I would think the operating systems
affect speed mostly through 1) the font server, 2) memory allocation, and 3)
the Guile implementation.
I timed one big score, Movement 1 of
52 matches
Mail list logo
