Freetype2/win32 conversion
Since I am out for the weekend, I thought I would send some notes to the list about Freetype.
Well, it looks as though we are on our own, and must convert to Freetype on Win32, whether we like it or not. So I made a few changes:
Added more stuff to gtk24.zip (AGAIN! sorry) to include a freshly-built freetype6.dll, the fontconfig lib, and xmlparse.dll (required by fontconfig).
Added WITH_XFT to config.h.mingw, but it is commented out. Freetype will not actually be used unless you uncomment this.
I added '-lfontconfig' to the LIBS entry in Makefile.mingw.common.
Note: the '-lfontconfig' should be changed to '-lfontconfig-1.0.dll' . This is an error that the original builder of freetype6.dll made, that apparently I duplicated perfectly :) . This is likely the reason that the original dll references "fontconfig", and not "fontconfig.dll" or "libfontconfig-1.0.dll" Both of these are because fontconfig's build erroneously put '-lfontconfig' in its pkg-config file, even though the build is dynamic only. Look in /target/lib for the correct spelling of the .dll.a file. (This is also quite likely the reason for the crasher.)
Since the freetype6.dll I made has debug info, the crash reported the location to be at base/ftobjs.c, line 789 in the Freetype source. So to debug, someone might want to try putting breakpoints in FontInstance.cpp, and stepping until the crash happens. A font face * passes a NULL check, but fails a pointer->field reference. Sounds like an uninitialized value.
Anyway, these are just some notes that I hope might help someone working on this stuff.
Bob
Re-built the reference lib , "libfontconfig-1.dll.a" so that it points to the correct .dll. The error was in fontconfig.def; it just listed "LIBRARY fontconfig," which caused client code to try to link to a phantom DLL, "fontconfig" with no extension.
But this does not stop the crashing in the presence of a <text> node. It is still in the same place as Thursday, in Freetype's base/ftobjs.c, line 789. Reproduction is simple. Just load "About" or one of the tutorials.
Uploaded another gtk24.zip, with this fix, and updated Makefile.mingw.common to use the proper link items. (Don't want another download? Help me fix this! ;-)
Also uploaded Inkscape0409131105.zip, so you can see the bug for yourself. Added gdb.exe to the distro, to help with backtraces.
Anyway, that is the current status.
Bob
Bob Jamison wrote:
Since I am out for the weekend, I thought I would send some notes to the list about Freetype.
Well, it looks as though we are on our own, and must convert to Freetype on Win32, whether we like it or not. So I made a few changes:
Added more stuff to gtk24.zip (AGAIN! sorry) to include a freshly-built freetype6.dll, the fontconfig lib, and xmlparse.dll (required by fontconfig).
Added WITH_XFT to config.h.mingw, but it is commented out. Freetype will not actually be used unless you uncomment this.
I added '-lfontconfig' to the LIBS entry in Makefile.mingw.common.
Note: the '-lfontconfig' should be changed to '-lfontconfig-1.0.dll' . This is an error that the original builder of freetype6.dll made, that apparently I duplicated perfectly :) . This is likely the reason that the original dll references "fontconfig", and not "fontconfig.dll" or "libfontconfig-1.0.dll" Both of these are because fontconfig's build erroneously put '-lfontconfig' in its pkg-config file, even though the build is dynamic only. Look in /target/lib for the correct spelling of the .dll.a file. (This is also quite likely the reason for the crasher.)
Since the freetype6.dll I made has debug info, the crash reported the location to be at base/ftobjs.c, line 789 in the Freetype source. So to debug, someone might want to try putting breakpoints in FontInstance.cpp, and stepping until the crash happens. A font face * passes a NULL check, but fails a pointer->field reference. Sounds like an uninitialized value.
Anyway, these are just some notes that I hope might help someone working on this stuff.
Bob
It works! Please try downloading this version:
(it was an error in FontFactory initializing the wrong font engine on Win32. Not FontInstance's fault)
http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409131227....
Sooooo..... who's buying the first round at the pub?
Bob
Bob Jamison wrote:
Re-built the reference lib , "libfontconfig-1.dll.a" so that it points to the correct .dll. The error was in fontconfig.def; it just listed "LIBRARY fontconfig," which caused client code to try to link to a phantom DLL, "fontconfig" with no extension.
But this does not stop the crashing in the presence of a <text> node. It is still in the same place as Thursday, in Freetype's base/ftobjs.c, line 789. Reproduction is simple. Just load "About" or one of the tutorials.
Uploaded another gtk24.zip, with this fix, and updated Makefile.mingw.common to use the proper link items. (Don't want another download? Help me fix this! ;-)
Also uploaded Inkscape0409131105.zip, so you can see the bug for yourself. Added gdb.exe to the distro, to help with backtraces.
Anyway, that is the current status.
Bob
So, now that it works with Freetype2, I would like to remove the pango_win32* stuff and the '#ifdef WITH_XFT' switches from:
main.cpp llibnrtype/font-instance.h ibnrtype/FontFactory.cpp libnrtype/FontInstance.cpp
and any config.h's or Makefiles
Does anyone object to this? I see no OSX-specific switches, so I don't think that it would affect them.
Bob
Bob Jamison wrote:
It works! Please try downloading this version:
...blah ... blah.. droning endlessly ....
http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409131227....
bulia byak wrote:
(it was an error in FontFactory initializing the wrong font engine on Win32. Not FontInstance's fault)
Admirable work Bob! Thank you! That removes an immense burden from my conscience :)
Well, now that it is done, I am glad that it is done. It is much better to have a single set of Pango code for the platforms. We can let someone else worry about portability.
Bob
Hello,
as I'm working on, two dialog issues appear:
1., dialogs autohide when inkscape lose focus.
yes, it is an amazing feature, but i want to disable it.
2., dialogs reopen at start:
I arrange some dialogs (text, fill, transform), and it would be fine to open these at starting.
(3). I think you already work on dockable dialogs.
All I need is only information about these features, 'cause I do not want to work in front of inkscape's official plans.
Thanks, Aewyn
Selecting a new font-family in text dialog (with up/down keys) it changes the preview only when hitting spacebar or clicking by mouse.
In this way it is very hard to search for an appropriate font. The preview must change as instantly, as walking on font-list.
Is there any simple way to change this?
Thanks, Aewyn
Selecting a new font-family in text dialog (with up/down keys) it changes the preview only when hitting spacebar or clicking by mouse.
In this way it is very hard to search for an appropriate font. The preview must change as instantly, as walking on font-list.
Is there any simple way to change this?
Maybe. Experiment :)
(I mean, experiment with the code - there's no way to change this without changing the code, that's for sure)
1., dialogs autohide when inkscape lose focus.
yes, it is an amazing feature, but i want to disable it.
What do you mean by "autohide"? Which platform? Have you tried to change Preferences > Windows settings?
2., dialogs reopen at start:
I arrange some dialogs (text, fill, transform), and it would be fine to open these at starting.
Yes, that would be nice, and not too difficult to do.
(3). I think you already work on dockable dialogs.
Yes, though it seems that this work has slowed down now.
Hello,
unfortunately I run into a bug, what needs -I am afraid of- complete rethinking of dispaying.
- just draw one rectange - change stroke paint to any color - change stroke style dashes to the first dash style (dotted, or anything) - change stroke style width 0.5 or below
And now, try to zoom to it.
In my machine (1.2GHz Tua) it takes seconds. And it is only one (!) rectangle. :(
Please say some promising.
Thanks, Aewyn
- just draw one rectange
- change stroke paint to any color
- change stroke style dashes to the first dash style
(dotted, or anything)
- change stroke style width 0.5 or below
And now, try to zoom to it.
In my machine (1.2GHz Tua) it takes seconds. And it is only one (!) rectangle. :(
Please say some promising.
I don't know what to say. Of course displaying dashes is slower than solid stroke. But not by much. And certainly not seconds. Maybe a fraction of a second to zoom to 25600% and back.
Where it DOES take seconds is if you use one of the LAST dash patterns in the list, not the first one. For example 0.01 0.01 really puts it under stress. But that is to be expected because it draws a hundred of dashes per each stroke width. Probably this can be displayed faster, but I don't see this as a problem because these dash patterns are not very practical anyway. They're there mostly for fun :)
Maybe my computer is slow, but it is really-really s l o w ;)
anyway, is there any cache mechanism to redisplay draw? It is seem no, because (in KDE) when inkscape move to top of the windows again, it seems redraws svg from scratch.
dashed lines: I realized, that you think of inkscape as an application suited for draws. But, this is not the case ;)
Vector drawing apps are very good (better then page layout apps, like Quark/PageMaker/Scribus) at small documents: invitations, certificates, menus (in restaurant).
These docs need full power of drawing capabilities and typographic tools too. (this is why I'am enforcing better text tools and multi page possibilies)
And of course these docs use lots of rectangles with fine dashed borders. :)
Regards, Aewyn
On Tuesday 14 September 2004 06:56, bulia byak wrote:
- just draw one rectange
- change stroke paint to any color
- change stroke style dashes to the first dash style
(dotted, or anything)
- change stroke style width 0.5 or below
And now, try to zoom to it.
In my machine (1.2GHz Tua) it takes seconds. And it is only one (!) rectangle. :(
Please say some promising.
I don't know what to say. Of course displaying dashes is slower than solid stroke. But not by much. And certainly not seconds. Maybe a fraction of a second to zoom to 25600% and back.
Where it DOES take seconds is if you use one of the LAST dash patterns in the list, not the first one. For example 0.01 0.01 really puts it under stress. But that is to be expected because it draws a hundred of dashes per each stroke width. Probably this can be displayed faster, but I don't see this as a problem because these dash patterns are not very practical anyway. They're there mostly for fun :)
And of course these docs use lots of rectangles with fine dashed borders. :)
What are you talking about? Show me an example of a document that uses 0.01 0.01 dashes. I bet there's none.
And all other dash patterns in the list are displayed quickly enough for real work.
OK, I guess I should better remove that pattern from the list so as to not induce unwarranted speculations about Inkscape purpose :)
Seriously, we're working on everything. On text. On display speed. On more features. It's just very difficult, see? If we're lacking in some area, it's an opportunity for you to help out. The "purpose" of Inkscape emerges as an average of intentions of all who work on it.
What are you talking about? Show me an example of a document that uses 0.01 0.01 dashes.
As I wrote it was one 16x28cm rectangle with 0.5 point width, with dotted line (it is the first on the list).
I think it is nothing extreme (so no 0.01 fine dotted)
And yes, it is extremly slow. But now I realized, that zoom is very fast while the zoom <=100. Very very fast. But, when zoom is 101% it will be very very slow.
Please, try it.
If we're lacking in some area, it's an opportunity for you to help out.
Exactly this, what I want to do. :)
Bye, Aewyn
As I wrote it was one 16x28cm rectangle with 0.5 point width, with dotted line (it is the first on the list).
I think it is nothing extreme (so no 0.01 fine dotted)
And yes, it is extremly slow. But now I realized, that zoom is very fast while the zoom <=100. Very very fast. But, when zoom is 101% it will be very very slow.
Either something is wrong with your system, or we're talking subjective. Can you devise a numerical measure of this "very very slow" so I could reproduce it and compare? On my system, it's quite fast. Not lightning fast, but certainly good enough to not be annoying.
On Tuesday 14 September 2004 20:06, bulia byak wrote:
As I wrote it was one 16x28cm rectangle with 0.5 point width, with dotted line (it is the first on the list).
I think it is nothing extreme (so no 0.01 fine dotted)
And yes, it is extremly slow. But now I realized, that zoom is very fast while the zoom <=100. Very very fast. But, when zoom is 101% it will be very very slow.
Either something is wrong with your system, or we're talking subjective. Can you devise a numerical measure of this "very very slow" so I could reproduce it and compare? On my system, it's quite fast. Not lightning fast, but certainly good enough to not be annoying.
One of this rectangle takes 2 seconds to draw. Ctrl+D four times, so 5 of this rectangles takes 10 seconds.
I attach the svg. But this appears above 100% zoom.
Bye, Aewyn
On Tue, 2004-09-14 at 14:06, bulia byak wrote:
As I wrote it was one 16x28cm rectangle with 0.5 point width, with dotted line (it is the first on the list).
I think it is nothing extreme (so no 0.01 fine dotted)
And yes, it is extremly slow. But now I realized, that zoom is very fast while the zoom <=100. Very very fast. But, when zoom is 101% it will be very very slow.
Either something is wrong with your system, or we're talking subjective. Can you devise a numerical measure of this "very very slow" so I could reproduce it and compare? On my system, it's quite fast. Not lightning fast, but certainly good enough to not be annoying.
I think your machine is too fast.
I experience the slowdown as well; at higher zoom levels (~2000% or so), Inkscape is effectively unusable, as moving a node in a simple path might take at least three seconds before the display updates; Inkscape is completely unresponsive (CPU pegged) in the meantime.
Editing the same document at lower zoom levels is much more responsive.
I'm completely at a loss as to what mechanism would cause this behavior. As far as I know, none of our data structures are scale-dependent, except perhaps in the display cache.
It would probably be worthwhile for me to do a profiling build and see where all this CPU time is going. I've been doing mostly art projects lately [hence my quietness], so this particular bug starting to become a severe personal annoyance.
-mental
participants (4)
-
Aewyn -
Bob Jamison -
bulia byak -
MenTaLguY