Status of Inkscape 0.91 Release
2. Chill. DONE Development focuses on wrapping up DONE Disable features that aren't finished Identify 'make distcheck' issues Identify any critical OSX/Win32 packaging issues Identify remaining writing needed for Release Notes. DONE Regressions Bug Hunt: 500 points Update tutorials and other docs
Can you help me identify where we are with the remaining items in the above list?
1. I ran 'make distcheck' and hit an error:
CXX event-log.o ../../src/event-log.cpp:11:33: fatal error: util/signal-blocker.h: No such file or directory compilation terminated.
There were also a bunch of errors in libcroco, that'll all need cleaned up.
2. I have zero insights into OSX or Win32 packaging. Can someone give me a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about?
(I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.)
3. I reviewed the ReleaseNotes a few months back and they looked really solid. Are there any areas you see where we need more attention?
4. Which features from this release need to have documentation and/or tutorials made? Is there any other tutorial or documentation work that will require tracking with the release?
Bryce
Hi,
Le Mardi 18 mars 2014 8h36, Bryce Harrington <bryce@...961...> a écrit : 2. I have zero insights into OSX or Win32 packaging.
We still have performance issues on Win32 with recent Cairo libs (1.12+). Related Free Desktop bug report: https://bugs.freedesktop.org/show_bug.cgi?id=71833 Related Inkscape thread: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tt4966631.html#none
The bug is a bit difficult to investigate because it only affects some (but not all) intel graphic cards, and on Windows only. I'm still not sure the bug comes from the Cairo lib or the way we use it. Note that the win32 devlibs still uses an old 1.11.2 Cairo lib (not affected).
IIRC there are some other win32 related things to fix. I'll try to give a list later today.
Regards, -- Nicolas
On Tue, Mar 18, 2014 at 09:12:24AM +0000, Nicolas Dufour wrote:
Hi,
Le Mardi 18 mars 2014 8h36, Bryce Harrington <bryce@...961...> a écrit : 2. I have zero insights into OSX or Win32 packaging.
We still have performance issues on Win32 with recent Cairo libs (1.12+). Related Free Desktop bug report: https://bugs.freedesktop.org/show_bug.cgi?id=71833 Related Inkscape thread: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tt4966631.html#none
The bug is a bit difficult to investigate because it only affects some (but not all) intel graphic cards, and on Windows only. I'm still not sure the bug comes from the Cairo lib or the way we use it. Note that the win32 devlibs still uses an old 1.11.2 Cairo lib (not affected).
IIRC there are some other win32 related things to fix. I'll try to give a list later today.
Thanks, that'd be great.
Sounds like you could work around this bug by staying on the older cairo library version?
Regards,
Nicolas
Hi,
Le Mercredi 19 mars 2014 6h42, Bryce Harrington <bryce@...961...> a écrit : Sounds like you could work around this bug by staying on the older cairo library version?
Yes, but IIRC the Cairo 1.12 branch is needed to fix some critical regressions...
Here's the list of all the bugs tagged win32 and milestoned 0.91: * Bug #802904 no svg file preview on Windows, build 10356 (regression) https://bugs.launchpad.net/inkscape/+bug/802904 * Bug #1271938 New From Template dialog doesn't show the preview image on Windows (related to #802904) https://bugs.launchpad.net/inkscape/+bug/1271938 * Bug #1054416 bitmap pattern prints at wrong resolution (regression) https://bugs.launchpad.net/inkscape/+bug/1054416 * Bug #481242 Inkscape 0.47pre4-1: Russian characters are lost at an insert of a figure from a clipboard (fixed r10045, but broken again later) https://bugs.launchpad.net/inkscape/+bug/481242 * Bug #1189846 Bug with slider textfield (UI regression) https://bugs.launchpad.net/inkscape/+bug/1189846
The missing icons bug is particularly visible on Windows, but also affects other operating systems depending on the theme used: Bug #1269698 Preferences, Undo, Redo and Revert stock icons are missing (UI regression) https://bugs.launchpad.net/inkscape/+bug/1269698
The Cairo 1.12 bug is not reported in LP (freedesktop bug tracker only): #71833 - Cairo 1.12+ very slow on Windows https://bugs.freedesktop.org/show_bug.cgi?id=71833
Additionally we still have some old win32 crashers waiting for a fix: https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-imp...
On Wed, Mar 19, 2014 at 09:10:08AM +0000, Nicolas Dufour wrote:
Hi,
Le Mercredi 19 mars 2014 6h42, Bryce Harrington <bryce@...961...> a écrit : Sounds like you could work around this bug by staying on the older cairo library version?
Yes, but IIRC the Cairo 1.12 branch is needed to fix some critical regressions...
Frankly, the Cairo project seems pretty inactive right now to me. Even were it highly active, most of the folks are Linux guys so Win32 issues wouldn't be flying very high on their radar.
Not to say this doesn't deserve to get looked into, but... I think you're going to need a strong Plan B. I think if we end up blocked waiting for fixes from Cairo, we'll never get the release out the door.
Possibly something can be adjusted on the Inkscape side. Or perhaps you can stick with the older cairo library (perhaps cherrypicking patches for any bug fixes you can't live without).
Here's the list of all the bugs tagged win32 and milestoned 0.91:
- Bug #802904 no svg file preview on Windows, build 10356 (regression) https://bugs.launchpad.net/inkscape/+bug/802904
- Bug #1271938 New From Template dialog doesn't show the preview image on Windows (related to #802904) https://bugs.launchpad.net/inkscape/+bug/1271938
- Bug #1054416 bitmap pattern prints at wrong resolution (regression) https://bugs.launchpad.net/inkscape/+bug/1054416
- Bug #481242 Inkscape 0.47pre4-1: Russian characters are lost at an insert of a figure from a clipboard (fixed r10045, but broken again later) https://bugs.launchpad.net/inkscape/+bug/481242
- Bug #1189846 Bug with slider textfield (UI regression) https://bugs.launchpad.net/inkscape/+bug/1189846
The missing icons bug is particularly visible on Windows, but also affects other operating systems depending on the theme used: Bug #1269698 Preferences, Undo, Redo and Revert stock icons are missing (UI regression) https://bugs.launchpad.net/inkscape/+bug/1269698
Thanks for this list. I notice none of these are set to higher than Medium importance. From a brief perusal the importances sound to be set appropriately; all the bugs either have a work around or affect just narrow use cases. They don't appear to present a risk of release blocking, and none are issues particular to packaging. Hopefully some or all can get tackled during the regular bug hunt, and I'd encourage you to keep tabs on them, but I don't think they need to be on the critical packaging issues list.
The Cairo 1.12 bug is not reported in LP (freedesktop bug tracker only): #71833 - Cairo 1.12+ very slow on Windows https://bugs.freedesktop.org/show_bug.cgi?id=71833
Even though this isn't a packaging bug and it sounds like you have a possible workaround, if you open a bug in LP with a link to the FDO bz entry, I can include this one in the critical packaging list.
Additionally we still have some old win32 crashers waiting for a fix: https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-imp...
Thanks, this is a good list. Hopefully many of these can get resolved during the general bug hunt. Even though they're not regressions, crash bugs are quite bad - if there are any that are widespread and a lot of people are hitting them, please bump the importance up to Critical and that will put them at the top of my radar.
Bryce
Just to be sure, there are problems with the unit refactoring so some features are broken when using units different than px (notably mm). Are these issues going to be ignored and left for this release? My opinion is that they are serious enough to affect usability.
Also, there are missing icons on the toolbox and in menus (Windows only?): for sure this is a minor issue but IMHO releasing a broken interface is not nice.
-- View this message in context: http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-tp4969769p4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I'll answer by myself: the next Frost phase will be the correct time to address those issues. Sorry, I didn't read the plan carefully enough.
-- View this message in context: http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-tp4969769p4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Tue, Mar 18, 2014 at 02:45:39AM -0700, LucaDC wrote:
Also, there are missing icons on the toolbox and in menus (Windows only?): for sure this is a minor issue but IMHO releasing a broken interface is not nice.
Could you make sure there is a bug report filed on the missing icons?
Thanks, Bryce
Bryce Harrington-3 wrote
On Tue, Mar 18, 2014 at 02:45:39AM -0700, LucaDC wrote:
Also, there are missing icons on the toolbox and in menus (Windows only?): for sure this is a minor issue but IMHO releasing a broken interface is not nice.
Could you make sure there is a bug report filed on the missing icons?
AFAIU the report already exists: https://bugs.launchpad.net/bugs/1269698.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-tp4969769p4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, Mar 19, 2014 at 12:42:30AM -0700, LucaDC wrote:
Bryce Harrington-3 wrote
On Tue, Mar 18, 2014 at 02:45:39AM -0700, LucaDC wrote:
Also, there are missing icons on the toolbox and in menus (Windows only?): for sure this is a minor issue but IMHO releasing a broken interface is not nice.
Could you make sure there is a bug report filed on the missing icons?
AFAIU the report already exists: https://bugs.launchpad.net/bugs/1269698.
Thanks!
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-tp4969769p4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
hi,
- Which features from this release need to have documentation and/or
tutorials made? Is there any other tutorial or documentation work that will require tracking with the release?
i am right now working on a tutorial / faq / compatibility list for the plotting extension, but i am not quite sure where to put it / from where to link it.
TimeWaster
On 18.3.2014 08:35, Bryce Harrington wrote:
- Chill. DONE Development focuses on wrapping up DONE Disable features that aren't finished Identify 'make distcheck' issues Identify any critical OSX/Win32 packaging issues Identify remaining writing needed for Release
Notes. DONE Regressions Bug Hunt: 500 points Update tutorials and other docs
Can you help me identify where we are with the remaining items in the above list?
- I ran 'make distcheck' and hit an error:
CXX event-log.o ../../src/event-log.cpp:11:33: fatal error: util/signal-blocker.h: No such file or directory compilation terminated.
There were also a bunch of errors in libcroco, that'll all need cleaned up.
- I have zero insights into OSX or Win32 packaging. Can someone give
me a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about?
(I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.)
- I reviewed the ReleaseNotes a few months back and they looked
really solid. Are there any areas you see where we need more attention?
- Which features from this release need to have documentation and/or
tutorials made? Is there any other tutorial or documentation work that will require tracking with the release?
Bryce
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Mar 18, 2014 at 10:46:40AM +0100, TimeWaster wrote:
hi,
- Which features from this release need to have documentation and/or
tutorials made? Is there any other tutorial or documentation work that will require tracking with the release?
i am right now working on a tutorial / faq / compatibility list for the plotting extension, but i am not quite sure where to put it / from where to link it.
TimeWaster
Specifically, the tutorials I'm concerned about as part of the release, are the ones that appear in the Help > Tutorials menu in Inkscape itself. Tutorials hosted on the web in general are of course great, but aren't constrained with the release. :-)
Bryce
On Tue, 2014-03-18 at 22:47 -0700, Bryce Harrington wrote:
Specifically, the tutorials I'm concerned about as part of the release, are the ones that appear in the Help > Tutorials menu in Inkscape itself.
If these were packaged separately, it'd be easier to edit them and to package them after a release.
Martin,
On Wed, Mar 19, 2014 at 07:46:57AM -0400, Martin Owens wrote:
On Tue, 2014-03-18 at 22:47 -0700, Bryce Harrington wrote:
Specifically, the tutorials I'm concerned about as part of the release, are the ones that appear in the Help > Tutorials menu in Inkscape itself.
If these were packaged separately, it'd be easier to edit them and to package them after a release.
Martin,
Quite true, and I love that idea. We should definitely get that on the roadmap.
But even with things split out, we still have the scheduling problem of getting old tutorials updated, new tutorials written, translated, etc. and done by the time the release is shipped.
But it would be nice to decouple updates to content-ish bits separately from the main executable package. Perhaps something we could consider for 0.92.
For this release, are there any major new features that we ought to be providing tutorials for? Or any feature changes that would be worth including in the existing tutorials?
Bryce
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issues
configure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
dan (packager for fink)
-- Daniel Macks dmacks@...2516...
On 2014-03-18 12:32 +0100, Daniel Macks wrote:
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issuesconfigure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
Discussed in the comments of these reports: - https://bugs.launchpad.net/inkscape/+bug/1133014 - https://bugs.launchpad.net/inkscape/+bug/1239370
Request to migrate OS X port to lcms2 tracked in: - https://bugs.launchpad.net/inkscape/+bug/1024344
AFAICT building with lcms1 or with lcms2 on OS X seems ok (personally tested on OS X 10.7.5, with trunk only), as long as there are not both libraries loaded at runtime (pulled in by another shared library, or due to overlinking (e.g. in earlier MacPorts versions)).
Regards, V
On Tue, Mar 18, 2014 at 01:13:52PM +0100, su_v wrote:
On 2014-03-18 12:32 +0100, Daniel Macks wrote:
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issuesconfigure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
Discussed in the comments of these reports:
Request to migrate OS X port to lcms2 tracked in:
AFAICT building with lcms1 or with lcms2 on OS X seems ok (personally tested on OS X 10.7.5, with trunk only), as long as there are not both libraries loaded at runtime (pulled in by another shared library, or due to overlinking (e.g. in earlier MacPorts versions)).
Thanks Dan and su_v, this sounds like exactly the sort of packaging problem we want to get resolved up front. Can you two compare notes in more detail and determine if this is indeed a real problem, and let me know the plan of action for addressing it?
Bryce
On 2014-03-19 06:50 +0100, Bryce Harrington wrote:
On Tue, Mar 18, 2014 at 01:13:52PM +0100, su_v wrote:
On 2014-03-18 12:32 +0100, Daniel Macks wrote:
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issuesconfigure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
Discussed in the comments of these reports:
Request to migrate OS X port to lcms2 tracked in:
AFAICT building with lcms1 or with lcms2 on OS X seems ok (personally tested on OS X 10.7.5, with trunk only), as long as there are not both libraries loaded at runtime (pulled in by another shared library, or due to overlinking (e.g. in earlier MacPorts versions)).
Thanks Dan and su_v, this sounds like exactly the sort of packaging problem we want to get resolved up front. Can you two compare notes in more detail and determine if this is indeed a real problem, and let me know the plan of action for addressing it?
In my understanding 'lcms1 vs lcms2' on OS X is not a packaging issue, it's a porting issue. A possible solution would be a minor change to simply remove the restricting test in 'configure.ac' (the patch attached in bug #1024344 still applies). I'm waiting/hoping for a reply or comment by Jon Cruz (I asked him the same question on irc the night before this issue was raised here on the mailing list).
As commented in the referenced bug reports, personally I did not want to change configure.ac to enable lcms2 detection (and usage) on OS X without prior feedback about (Jon's) builds on SL: detailed information about what type of crashes had been the reason for the restriction, and whether they still occur with clean builds of current trunk using latest lcms2 2.4 or 2.5 (current version in MacPorts), is not available (as dan already mentioned in his mail).
Once lcms2 support is allowed for OS X builds and confirmed to work on OS X, support for lcms1 (including all related ifdefs in the code) could be removed completely, as requested in bug #1133014 - that's not really a porting or packaging issue though.
Regards, V
On Wed, Mar 19, 2014 at 09:45:14AM +0100, su_v wrote:
On 2014-03-19 06:50 +0100, Bryce Harrington wrote:
On Tue, Mar 18, 2014 at 01:13:52PM +0100, su_v wrote:
On 2014-03-18 12:32 +0100, Daniel Macks wrote:
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issuesconfigure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
Discussed in the comments of these reports:
Request to migrate OS X port to lcms2 tracked in:
AFAICT building with lcms1 or with lcms2 on OS X seems ok (personally tested on OS X 10.7.5, with trunk only), as long as there are not both libraries loaded at runtime (pulled in by another shared library, or due to overlinking (e.g. in earlier MacPorts versions)).
Thanks Dan and su_v, this sounds like exactly the sort of packaging problem we want to get resolved up front. Can you two compare notes in more detail and determine if this is indeed a real problem, and let me know the plan of action for addressing it?
In my understanding 'lcms1 vs lcms2' on OS X is not a packaging issue, it's a porting issue.
Actually, porting issues are probably relevant to track with the packaging issues too, if they're severe enough to risk being a "show stopper" class problem that blocks the release.
A possible solution would be a minor change to simply remove the restricting test in 'configure.ac' (the patch attached in bug #1024344 still applies). I'm waiting/hoping for a reply or comment by Jon Cruz (I asked him the same question on irc the night before this issue was raised here on the mailing list).
Okay, thanks. Give Jon one more ping and if you don't get an answer within a couple days, go ahead and commit it. This looks like it would be trivial to back out if there were problems, and the more time we have it in there for folks to test the more confidence we'll gain in it.
As commented in the referenced bug reports, personally I did not want to change configure.ac to enable lcms2 detection (and usage) on OS X without prior feedback about (Jon's) builds on SL: detailed information
SL?
about what type of crashes had been the reason for the restriction, and whether they still occur with clean builds of current trunk using latest lcms2 2.4 or 2.5 (current version in MacPorts), is not available (as dan already mentioned in his mail).
Once lcms2 support is allowed for OS X builds and confirmed to work on OS X, support for lcms1 (including all related ifdefs in the code) could be removed completely, as requested in bug #1133014 - that's not really a porting or packaging issue though.
Right, and unless having it there causes an actual problem, I would suggest leaving it there. That way post-release if people find problems with cms2, they'd need only a minimal patch to revert back to legacy to work around the problem. Then once 0.91 is out the door, the cruft code can go!
Bryce
On 2014-03-20 10:00 +0100, Bryce Harrington wrote:
On Wed, Mar 19, 2014 at 09:45:14AM +0100, su_v wrote:
As commented in the referenced bug reports, personally I did not want to change configure.ac to enable lcms2 detection (and usage) on OS X without prior feedback about (Jon's) builds on SL: detailed information
SL?
Oops - missed that earlier, sorry: SL stands for 'Mac OS X Snow Leopard' (aka Mac OS X 10.6).
I have been routinely building Gimp (my version is called McGimp :) ) on a Mac and I don't have any issues with lcms1 or 2. Gimp 2.9 uses lcm2.
I am unable to build the current Inkscape stable version due to issues with PDF. I was able figure out the missing Gfxsymbols but not some other symbols. Sorry to be vague, as I am not in front of my Mac right now.
If it's possible to get a tarball of the current frost version, I can see if there are any issues with Win 64 and OSX.
Thanks, Partha
On Tue, Mar 18, 2014 at 7:32 AM, Daniel Macks <dmacks@...2516...> wrote:
On Tue, 18 Mar 2014 00:35:48 -0700, Bryce Harrington <bryce@...961...> wrote:
Identify any critical OSX/Win32 packaging issuesconfigure.ac still only accepts lcms (not lcms2) on OS X, with embedded comment "lcms 2.2 & 2.3 have problems on OSX". Upstream now has lcms 2.4; is the problem still present? I don't see a link to a bug report or discussion to be able to know what the problem is.
dan (packager for fink)
-- Daniel Macks dmacks@...2516...
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Mar 18, 2014 at 06:01:39PM -0400, Partha Bagchi wrote:
I have been routinely building Gimp (my version is called McGimp :) ) on a Mac and I don't have any issues with lcms1 or 2. Gimp 2.9 uses lcm2.
I am unable to build the current Inkscape stable version due to issues with PDF. I was able figure out the missing Gfxsymbols but not some other symbols. Sorry to be vague, as I am not in front of my Mac right now.
Please do follow up with more on this build issue when you can.
If it's possible to get a tarball of the current frost version, I can see if there are any issues with Win 64 and OSX.
We're not quite to Frost yet, so haven't begun posting tarballs.
We used to post daily snapshot tarballs, but I'm not finding links to this; anyone know what happened to them?
Bryce
On Wed, Mar 19, 2014 at 2:03 AM, Bryce Harrington <bryce@...961...
wrote:
On Tue, Mar 18, 2014 at 06:01:39PM -0400, Partha Bagchi wrote:
I have been routinely building Gimp (my version is called McGimp :) ) on
a
Mac and I don't have any issues with lcms1 or 2. Gimp 2.9 uses lcm2.
I am unable to build the current Inkscape stable version due to issues with PDF. I was able figure out the missing Gfxsymbols but not some other symbols. Sorry to be vague, as I am not in front of my Mac right now.
Please do follow up with more on this build issue when you can.
Will do sometime soon. Perhaps this weekend.
If it's possible to get a tarball of the current frost version, I can see if there are any issues with Win 64 and OSX.
We're not quite to Frost yet, so haven't begun posting tarballs.
We used to post daily snapshot tarballs, but I'm not finding links to this; anyone know what happened to them?
Bryce
Any news on the tarballs? I'm not familiar with bzr and would appreciate a
link to the tarballs.
Thanks! Partha
On Wed, Mar 19, 2014 at 4:07 PM, Partha Bagchi <partha1b@...400...> wrote:
Any news on the tarballs? I'm not familiar with bzr and would appreciate a link to the tarballs.
You can download tarballs right from the revision pages on launchpad. Here is a link to the latest revision page (as of my writing this): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13168
You'll find the "download tarball" link on that page.
Cheers, Josh
On Wed, Mar 19, 2014 at 04:34:58PM -0700, Josh Andler wrote:
On Wed, Mar 19, 2014 at 4:07 PM, Partha Bagchi <partha1b@...400...> wrote:
Any news on the tarballs? I'm not familiar with bzr and would appreciate a link to the tarballs.
You can download tarballs right from the revision pages on launchpad. Here is a link to the latest revision page (as of my writing this): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13168
You'll find the "download tarball" link on that page.
Cheers, Josh
Thanks Josh.
We'll also put together an inkscape-0.91-pre0.tar.gz hopefully within a week or so.
Bryce
Hello Bryce,
I was working on Win32 Installer using WIX-Toolset (Windows Installer xml). That tool creates long requested msi files. I never received feedback if the given msi are working or not for others. Currently I have a script that downloads the trunk files and create a msi without problems.
You can download them from the OSS-Marketplace where nightly builds are. You are guided to a one-drive that hosts the files: https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A!217
The msi is fine for me but it turned out that multilanguage installer (one installer that has multiple languages) is not trivial. That is where I stopped and can not go further without assistence.
regards,
Adib. --
On Tue, Mar 18, 2014 at 8:35 AM, Bryce Harrington <bryce@...961...
wrote:
...
- I have zero insights into OSX or Win32 packaging. Can someone give me
a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about?
(I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.)
...
Bryce
On Wed, Mar 19, 2014 at 11:08:28AM +0100, the Adib wrote:
Hello Bryce,
I was working on Win32 Installer using WIX-Toolset (Windows Installer xml). That tool creates long requested msi files. I never received feedback if the given msi are working or not for others. Currently I have a script that downloads the trunk files and create a msi without problems.
You can download them from the OSS-Marketplace where nightly builds are. You are guided to a one-drive that hosts the files: https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A!217
The msi is fine for me but it turned out that multilanguage installer (one installer that has multiple languages) is not trivial. That is where I stopped and can not go further without assistence.
Thanks Adib, I'll add this to the critical packaging issues list. At least we should be able to drum up some feedback for you on the msi installer.
Bryce
regards,
Adib.
On Tue, Mar 18, 2014 at 8:35 AM, Bryce Harrington <bryce@...961...
wrote:
...
- I have zero insights into OSX or Win32 packaging. Can someone give me
a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about?
(I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.)
...
Bryce
El mar, 18-03-2014 a las 00:35 -0700, Bryce Harrington escribió:
Can you help me identify where we are with the remaining items in the above list?
Hi, glad to see that things are moving forward.
I'd like to point an issue with caching that seems to be important enough to be discussed before releasing the new version. Cache, when enabled (default in devel version), seems to have a negative impact on redrawing when panning the visible area, causing tearing and making inkscape feel less responsive. It's probably just perceived and not a real performance issue, but it makes panning in 0.91 feel slower than in 0.48.
When I disable the cache with _INKSCAPE_DISABLE_CACHE=1 redrawing performance is much better (comparable to 0.48's or even better).
I'm not sure whether cache is for editing or rendering, other aspects are faster with cache enabled (like moving things without panning and turning on an off the visibility of layers, for instance).
Notice that this is not the bug I reported earlier past week with Cairo Master and zooming (that was fixed by Krzysztof), and it's not related to cairo master either. I get the same both with Cairo 1.12 from Debian testing repositories and with Cairo master.
I found (with su_v's help over IRC) these report and thread. They seem to be related:
https://bugs.launchpad.net/inkscape/+bug/1267208 http://inkscape.13.x6.nabble.com/Inkscape-performance-two-suggestions-td4969...
I tried to reproduce the problem in a minimal file and found something interesting: It only happens when an object in the visible area is larger than the visible portion of the artwork. In my example, I placed a star on a large rectangle (no outlines or filters, just two primitives and a text object), and could reproduce the tearing easily. I grabbed a screencast to illustrate the problem: https://dl.dropboxusercontent.com/u/255376/nocache-vs-cache.webm
Notice that the star could be replaced with a circle or a simple path and the text object doesn't have any impact on the issue. The cause seems to be the larger rectangle in the background. When cache is on it looks like it has to be re-drawn and cached and that seems to take longer than when cache is disabled.
Kind regards, Gez.
2014-03-19 20:32 GMT+01:00 Gez <listas@...3059...>:
El mar, 18-03-2014 a las 00:35 -0700, Bryce Harrington escribió:
Can you help me identify where we are with the remaining items in the above list?
Hi, glad to see that things are moving forward.
I'd like to point an issue with caching that seems to be important enough to be discussed before releasing the new version. Cache, when enabled (default in devel version), seems to have a negative impact on redrawing when panning the visible area, causing tearing and making inkscape feel less responsive. It's probably just perceived and not a real performance issue, but it makes panning in 0.91 feel slower than in 0.48.
When I disable the cache with _INKSCAPE_DISABLE_CACHE=1 redrawing performance is much better (comparable to 0.48's or even better).
I'm not sure whether cache is for editing or rendering, other aspects are faster with cache enabled (like moving things without panning and turning on an off the visibility of layers, for instance).
Notice that this is not the bug I reported earlier past week with Cairo Master and zooming (that was fixed by Krzysztof), and it's not related to cairo master either. I get the same both with Cairo 1.12 from Debian testing repositories and with Cairo master.
I found (with su_v's help over IRC) these report and thread. They seem to be related:
https://bugs.launchpad.net/inkscape/+bug/1267208 http://inkscape.13.x6.nabble.com/Inkscape-performance-two-suggestions-td4969...
I tried to reproduce the problem in a minimal file and found something interesting: It only happens when an object in the visible area is larger than the visible portion of the artwork. In my example, I placed a star on a large rectangle (no outlines or filters, just two primitives and a text object), and could reproduce the tearing easily. I grabbed a screencast to illustrate the problem: https://dl.dropboxusercontent.com/u/255376/nocache-vs-cache.webm
Notice that the star could be replaced with a circle or a simple path and the text object doesn't have any impact on the issue. The cause seems to be the larger rectangle in the background. When cache is on it looks like it has to be re-drawn and cached and that seems to take longer than when cache is disabled.
I think the constants used to choose which objects need to be cached need some tweaking. Right now each object has a score that depends on its on-screen area and the complexity of its filter, and the scores are assigned rather arbitrarily. The slowdown is probably caused by many small objects being cached - more time is spent on copying the image data around than on rendering.
Regards, Krzysztof
El mié, 19-03-2014 a las 20:42 +0100, Krzysztof Kosiński escribió:
I grabbed a screencast to illustrate the problem: https://dl.dropboxusercontent.com/u/255376/nocache-vs-cache.webm
Notice that the star could be replaced with a circle or a simple path and the text object doesn't have any impact on the issue. The cause seems to be the larger rectangle in the background. When cache is on it looks like it has to be re-drawn and cached and that seems to take longer than when cache is disabled.
I think the constants used to choose which objects need to be cached need some tweaking. Right now each object has a score that depends on its on-screen area and the complexity of its filter, and the scores are assigned rather arbitrarily. The slowdown is probably caused by many small objects being cached - more time is spent on copying the image data around than on rendering.
Hi Krzysztof,
This file (the one I used for the screencast) has three objects, and one of the objects is irrelevant to the problem. None of them has any filters.
https://dl.dropboxusercontent.com/u/255376/cache-tearing-sample.svg
There's no tearing when the rectangle in the background is removed or scaled down to fit the visible are. The problem seems to be that it's big and goes beyond the limits of the visible portion of the document.
Gez.
participants (12)
-
Bryce Harrington -
Daniel Macks -
Gez -
Josh Andler -
Krzysztof Kosiński -
LucaDC -
Martin Owens -
Nicolas Dufour -
Partha Bagchi -
su_v -
the Adib -
TimeWaster