Cairo branch ready
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
Regards, Krzysztof
On 19/6/11 12:15, Krzysztof Kosiński wrote:
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
On Mac OS X 10.5.8 (Intel, 32bit) - r9597 (gtk/x11 2.24.4) with cairo 1.10.2 - r9595 (gtk/quartz 2.24.4) with cairo 1.11.2 I still have the issue that outline view mode always uses (apparently) solid white for the outlines (no matter what background color is used). This makes outline view with default documents difficult to use ;)
What information can I provide to help debugging this issue?
~suv
W dniu 19 czerwca 2011 13:50 użytkownik ~suv <suv-sf@...58...> napisał:
On Mac OS X 10.5.8 (Intel, 32bit)
- r9597 (gtk/x11 2.24.4) with cairo 1.10.2
- r9595 (gtk/quartz 2.24.4) with cairo 1.11.2
I still have the issue that outline view mode always uses (apparently) solid white for the outlines (no matter what background color is used). This makes outline view with default documents difficult to use ;)
Forgot about that. This should now be fixed in r9598. Regards, Krzysztof
On 19/6/11 14:36, Krzysztof Kosiński wrote:
W dniu 19 czerwca 2011 13:50 użytkownik ~suv <suv-sf@...58...> napisał:
On Mac OS X 10.5.8 (Intel, 32bit)
- r9597 (gtk/x11 2.24.4) with cairo 1.10.2
- r9595 (gtk/quartz 2.24.4) with cairo 1.11.2
I still have the issue that outline view mode always uses (apparently) solid white for the outlines (no matter what background color is used). This makes outline view with default documents difficult to use ;)
Forgot about that. This should now be fixed in r9598.
Thx :) - fix confirmed with r9598 (gtk/x11 2.24.4) with cairo 1.10.2.
~suv
On 2011-06-19 12:15, Krzysztof Kosiński wrote:
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
I'm not that worried about devlibs, as long as the library works okay it's fine, as we bundle it with Inkscape anyway. I'm a bit more worried about the linux side of things, as there we do rely on the version of cairo that is bundled with distro's. So how is the situation there?
BTW, I assume we need this version because of fixes for some of the issues you encountered while working on the cairo branch.
On Sun, 2011-06-19 at 19:14 +0200, Jasper van de Gronde wrote:
On 2011-06-19 12:15, Krzysztof Kosiński wrote:
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
I'm not that worried about devlibs, as long as the library works okay it's fine, as we bundle it with Inkscape anyway. I'm a bit more worried about the linux side of things, as there we do rely on the version of cairo that is bundled with distro's. So how is the situation there?
Let's just get it merged. It will be some time before we make a new Inkscape release, giving Linux distros time to catch up. Maybe we can encourage the Cairo people into making a new release? 1.11.2 has been out since January.
Tav
On Jun 19, 2011, at 3:15 AM, Krzysztof Kosiński wrote:
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
I thought things only would require 1.10, which is out and available. It would be best to stay with that for now, so that we can if nothing else get things properly compatible via version checks, etc.
For the devlibs, I would very very strongly advise against using experimental unless it had been fully and carefully tested to support our needs. We're already having a lot of issues with tablet users, so it would be good to avoid such breakage. Keep in mind that bumping the devlibs to more unstable versions pushes a very heavy burden onto our lest technically adept yet largest audience. Breaking things in Windows, even in dailies, can really give Inkscape a bad name and hurt adoption.
On the other hand, those who can help identify and debug subtle issues from experimental builds can usually at least follow instructions to get their own environment going. That's different than the "pre-packaged for your convenience" windows devlibs in general.
2011/6/19 Jon Cruz <jon@...18...>
On Jun 19, 2011, at 3:15 AM, Krzysztof Kosiński wrote:
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
I thought things only would require 1.10, which is out and available. It would be best to stay with that for now, so that we can if nothing else get things properly compatible via version checks, etc.
You and I have discussed this numerous times. It doesn't require 1.12, but there are known bugs when using 1.10.
For the devlibs, I would very very strongly advise against using experimental unless it had been fully and carefully tested to support our needs. We're already having a lot of issues with tablet users, so it would be good to avoid such breakage. Keep in mind that bumping the devlibs to more unstable versions pushes a very heavy burden onto our lest technically adept yet largest audience. Breaking things in Windows, even in dailies, can really give Inkscape a bad name and hurt adoption.
Okay, but with tablets on Windows, in my experience the current devlibs actually recognize that I have a tablet attached as opposed to 0.48.1 (where it shows nothing). Either way, it's irrelevant because the tablet stuff is nonfunctional for me with either version of devlibs. I question if it's not just something broken within Inkscape as opposed to only being the devlibs at this point. Besides, I don't know any project that advocates using development/nightly builds for anything but testing.
It seems to make sense to me to make a notation of which build is the last nightly to use the current devlibs, so if people do run into issues with newer cairo, we can tell them the last known good one.
My vote is to move forward...
Cheers, Josh
On 19/6/11 22:11, Josh Andler wrote:
2011/6/19 Jon Cruz <jon@...18...>
For the devlibs, I would very very strongly advise against using experimental unless it had been fully and carefully tested to support our needs. We're already having a lot of issues with tablet users, so it would be good to avoid such breakage. Keep in mind that bumping the devlibs to more unstable versions pushes a very heavy burden onto our lest technically adept yet largest audience. Breaking things in Windows, even in dailies, can really give Inkscape a bad name and hurt adoption.
Okay, but with tablets on Windows, in my experience the current devlibs actually recognize that I have a tablet attached as opposed to 0.48.1 (where it shows nothing). Either way, it's irrelevant because the tablet stuff is nonfunctional for me with either version of devlibs. I question if it's not just something broken within Inkscape as opposed to only being the devlibs at this point. Besides, I don't know any project that advocates using development/nightly builds for anything but testing.
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases - devel for development builds from current trunk
This could ease the release process for the Windows packages without having to delve into reverting to older bzr revisions of the devlibs, while allowing to provide unstable development snapshots with more recent versions of cairo (and possibly Gtk+).
It seems to make sense to me to make a notation of which build is the last nightly to use the current devlibs, so if people do run into issues with newer cairo, we can tell them the last known good one.
The packaging script used for Mac OS X builds does create a text file listing essential data (OS version, compiler, versions of including libs) [1] for each completed build, and the text file gets uploaded to modevia together with the archive (DMG). Maybe something similar could be added to the packaging routines on Windows too, so that for each snapshot build uploaded to modevia [2] there's an accompanying, versioned readme file.
~suv
[1] latest file for today's snapshot: http://inkscape.modevia.com/macosx-snap/Inkscape-r10325-10.5+-UNIVERSAL-info.txt [2] http://inkscape.modevia.com/win32/?C=M;O=D
Cairo rendering merged in revision 10326.
2011/6/20 ~suv <suv-sf@...58...>:
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases
- devel for development builds from current trunk
Hmm... I should have done that a long time ago :) I can upload r23 (before I committed dev snapshot Cairo) as a separate branch to be used for stable.
Regards, Krzysztof
2011/6/20 Krzysztof Kosiński <tweenk.pl@...400...>:
Cairo rendering merged in revision 10326.
2011/6/20 ~suv <suv-sf@...58...>:
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases
- devel for development builds from current trunk
Hmm... I should have done that a long time ago :) I can upload r23 (before I committed dev snapshot Cairo) as a separate branch to be used for stable.
As a side note, Alex said he will look into adding the "good" cairo to our trunk PPA as well.
Cheers, Josh
On 2011-06-20 23:05, Krzysztof Kosiński wrote:
Cairo rendering merged in revision 10326.
2011/6/20 ~suv <suv-sf@...58...>:
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases
- devel for development builds from current trunk
Hmm... I should have done that a long time ago :) I can upload r23 (before I committed dev snapshot Cairo) as a separate branch to be used for stable.
I'm not against that if it's handled like Inkscape releases (so "stable" is just a kind of snapshot in time of a revision known to be more or less good), but once the Cairo branch is merged we'll need the new Cairo anyway... And until the next Inkscape release the devlibs are "devel" by default (more or less). If the "old" Cairo doesn't work satisfactorily with the cairo branch and the "new" cairo isn't stable enough for general use then we simply have a problem and shouldn't be merging the cairo branch at this point (very, very regrettably).
On the other hand, if the cairo branch only has very minor problems when used with the "old" cairo and/or the "new" cairo is generally usable, then what's the problem? Also, if the only problem is that the Windows builds of cairo aren't up-to-date enough yet, I'll gladly have a look to see if we can't just compile the latest version and use that.
BTW, the reason I'm not jumping at the opportunity to branch the devlibs is that having stable and devel branches tends to make stable branches outdated and devel branches unstable. Neither is very appealing to me. I think Inkscape generally has a very good policy of trying to ensure that trunk is more or less constantly usable.
On Tue, Jun 21, 2011 at 12:43 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
On 2011-06-20 23:05, Krzysztof Kosiński wrote:
Cairo rendering merged in revision 10326.
2011/6/20 ~suv <suv-sf@...58...>:
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases
- devel for development builds from current trunk
Hmm... I should have done that a long time ago :) I can upload r23 (before I committed dev snapshot Cairo) as a separate branch to be used for stable.
I'm not against that if it's handled like Inkscape releases (so "stable" is just a kind of snapshot in time of a revision known to be more or less good), but once the Cairo branch is merged we'll need the new Cairo anyway... And until the next Inkscape release the devlibs are "devel" by default (more or less). If the "old" Cairo doesn't work satisfactorily with the cairo branch and the "new" cairo isn't stable enough for general use then we simply have a problem and shouldn't be merging the cairo branch at this point (very, very regrettably).
On the other hand, if the cairo branch only has very minor problems when used with the "old" cairo and/or the "new" cairo is generally usable, then what's the problem? Also, if the only problem is that the Windows builds of cairo aren't up-to-date enough yet, I'll gladly have a look to see if we can't just compile the latest version and use that.
BTW, the reason I'm not jumping at the opportunity to branch the devlibs is that having stable and devel branches tends to make stable branches outdated and devel branches unstable. Neither is very appealing to me. I think Inkscape generally has a very good policy of trying to ensure that trunk is more or less constantly usable.
In this case, we're looking to push 0.48.2 in the very near future. We won't have sufficient testing time prior to that release to deem things kosher (in fact, given the push to have it be our stable branch, we won't). We will however have time with the unstable/newly stable libs to see if there are any blockers for when our 11.X release rolls around.
The big win here is that we can possibly prevent stuff like tablet support on Windows getting broken frequently. We can have the ability to really mess around and ensure that the latest and greatest continues to meet our needs (with tablets, neither 0.48.1 nor current devlibs work right with my win testing of a wacom).
Cheers, Josh
2011/6/21 Jasper van de Gronde <th.v.d.gronde@...528...>:
On the other hand, if the cairo branch only has very minor problems when used with the "old" cairo and/or the "new" cairo is generally usable, then what's the problem?
The "new" Cairo (1.11.2) is rather stable - I have used it on my desktop for several weeks and it hasn't caused me any problems. I have added it to Windows devlibs before merging.
I wouldn't describe the problems with "old" Cairo (1.10.2) as very minor - on large drawings the gradients will disappear at a certain zoom level. A radial gradient that fills an A4 page will disappear at around 400% zoom. Furthermore, large gradients will not line up correctly with their stops.
Regards, Krzysztof
On 22-06-11 02:32, Krzysztof Kosiński wrote:
2011/6/21 Jasper van de Gronde <th.v.d.gronde@...528...>:
On the other hand, if the cairo branch only has very minor problems when used with the "old" cairo and/or the "new" cairo is generally usable, then what's the problem?
The "new" Cairo (1.11.2) is rather stable - I have used it on my desktop for several weeks and it hasn't caused me any problems. I have added it to Windows devlibs before merging.
I wouldn't describe the problems with "old" Cairo (1.10.2) as very minor - on large drawings the gradients will disappear at a certain zoom level. A radial gradient that fills an A4 page will disappear at around 400% zoom. Furthermore, large gradients will not line up correctly with their stops.
Then, as far as I'm concerned I would recommend trying to get the Cairo branch in asap, put the "new" cairo in devlibs, celebrate and see what happens. If there is some major defect that didn't come up till now it probably won't come up until we put it out in the "wild" (among developers) anyway, and then we should have enough time before the next release to decide what we're going to do about it.
As was mentioned before by others, to facilitate point releases and such it might not be a bad idea to branch devlibs in the same way as is done with trunk.
Looking forward to the cairo branch being merged in trunk :)
W dniu 22 czerwca 2011 09:25 użytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisał:
Then, as far as I'm concerned I would recommend trying to get the Cairo branch in asap, put the "new" cairo in devlibs, celebrate and see what happens. If there is some major defect that didn't come up till now it probably won't come up until we put it out in the "wild" (among developers) anyway, and then we should have enough time before the next release to decide what we're going to do about it.
As was mentioned before by others, to facilitate point releases and such it might not be a bad idea to branch devlibs in the same way as is done with trunk.
Looking forward to the cairo branch being merged in trunk :)
The Cairo branch was already merged in revision 10326, and the new Cairo is in Devlibs revision 24.
Regards, Krzysztof
On 22-06-11 18:49, Krzysztof Kosiński wrote:
W dniu 22 czerwca 2011 09:25 użytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisał:
Then, as far as I'm concerned I would recommend trying to get the Cairo branch in asap, put the "new" cairo in devlibs, celebrate and see what happens. If there is some major defect that didn't come up till now it probably won't come up until we put it out in the "wild" (among developers) anyway, and then we should have enough time before the next release to decide what we're going to do about it.
As was mentioned before by others, to facilitate point releases and such it might not be a bad idea to branch devlibs in the same way as is done with trunk.
Looking forward to the cairo branch being merged in trunk :)
The Cairo branch was already merged in revision 10326, and the new Cairo is in Devlibs revision 24.
Gheesh, you don't watch trunk for a few days and suddenly the Cairo branch is there! :) Well done!
On 19/6/11 22:11, Josh Andler wrote:
2011/6/19 Jon Cruz <jon@...18...>
On Jun 19, 2011, at 3:15 AM, Krzysztof Kosiński wrote:
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
I thought things only would require 1.10, which is out and available. It would be best to stay with that for now, so that we can if nothing else get things properly compatible via version checks, etc.
You and I have discussed this numerous times. It doesn't require 1.12, but there are known bugs when using 1.10.
@Krzysztof - do you have notes or a list of known issues you could share? This could help with bug triage, if we don't have to test each new report against both versions of cairo.
With regard to the bug tracker - what tag should be use for bugs filed about the cairo renderer? Up to now, many reports about rendering glitches or errors are tagged with 'renderer', but new reports for current trunk better get a different tag (IMHO). Any proposals or preferences?
~suv
2011/6/21 ~suv <suv-sf@...58...>:
@Krzysztof - do you have notes or a list of known issues you could share? This could help with bug triage, if we don't have to test each new report against both versions of cairo.
Here they are:
Gradient rendering is imprecise https://bugs.freedesktop.org/show_bug.cgi?id=29470
Large gradients do not render https://bugs.freedesktop.org/show_bug.cgi?id=32215
Incorrect radial gradients when focus is outside of outermost circle https://bugs.freedesktop.org/show_bug.cgi?id=29521
With regard to the bug tracker - what tag should be use for bugs filed about the cairo renderer? Up to now, many reports about rendering glitches or errors are tagged with 'renderer', but new reports for current trunk better get a different tag (IMHO). Any proposals or preferences?
It could be "renderer-cairo"
Regards, Krzysztof
I just compiled rev. 10330 (devlibs rev. 24) under Windows XP and Inkscape couldn't find ibpixman-1-0.dll; manually copying it from the devlibs tree fixed the problem, of course.
2011/6/21 LucaDC <dicappello@...2144...>:
I just compiled rev. 10330 (devlibs rev. 24) under Windows XP and Inkscape couldn't find ibpixman-1-0.dll; manually copying it from the devlibs tree fixed the problem, of course.
Fixed in 10332. The build of Cairo from the GTK bundle has Pixman built in as a static library, but I couldn't figure out how to build it that way, so there's a separate Pixman DLL now and I forgot to put it in build.xml.
Regards, Krzysztof
On 19-6-2011 12:15, Krzysztof Kosiński wrote:
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Since noone seems to have replied so yet: Awesome work!!
:-) Johan
Krzysztof,
I checked the svg filters in rev 10330 on Kubuntu 10.04 and want to say you did a marvellous work !!!
Not only rendering speed is greatly improved for all categories of filters, but it seems that colors are also better.
Have a nice day, ivan
________________________________ De : Krzysztof Kosiński <tweenk.pl@...400...> À : inkscape-devel inkscape-devel@lists.sourceforge.net Cc : Jasper van de Gronde <th.v.d.gronde@...528...> Envoyé le : Dimanche 19 Juin 2011 12h15 Objet : [Inkscape-devel] Cairo branch ready
Hello
The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts.
Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs?
Regards, Krzysztof
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Does this mean that libnr will be retired soon?
With libcroco, libgdl and libnr all removed, that will very much cut the code-base down to size!
Joel
From my understanding, there is work that needs to be done in lib2geom
(specifically boolops from my understanding) before libnr can fully be retired. There may be more areas, but I'm unaware of what they are.
Cheers, Josh
On Wed, Jun 22, 2011 at 1:27 PM, Joel Holdsworth <joel@...1709...> wrote:
Does this mean that libnr will be retired soon?
With libcroco, libgdl and libnr all removed, that will very much cut the code-base down to size!
Joel
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
That's cool. I guess I'm quite interested in seeing all the lib* subfolders, and 2geom spun off on their own rather than living in the src directory, either that or retired altogether.
On 22/06/11 22:04, Josh Andler wrote:
From my understanding, there is work that needs to be done in lib2geom (specifically boolops from my understanding) before libnr can fully be retired. There may be more areas, but I'm unaware of what they are.
Cheers, Josh
On Wed, Jun 22, 2011 at 1:27 PM, Joel Holdsworth <joel@...1709...> wrote:
Does this mean that libnr will be retired soon?
With libcroco, libgdl and libnr all removed, that will very much cut the code-base down to size!
Joel
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2011/6/22 Josh Andler <scislac@...400...>:
From my understanding, there is work that needs to be done in lib2geom (specifically boolops from my understanding) before libnr can fully be retired. There may be more areas, but I'm unaware of what they are.
Boolops are handled by livarot, so removing libnr doesn't require boolops in 2Geom. But they will be required if want to get rid of livarot as well (and I think we do).
Regards, Krzysztof
2011/6/22 Joel Holdsworth <joel@...1709...>:
Does this mean that libnr will be retired soon?
90% of libnr was already removed. The only remaining things are: - NRRect and NRRectL, which are used rather pervasively in the SP tree. - NRPoint, which is used by livarot. - NRObject, which is something like a limited version of GObject and is used as the base class of the display tree.
Up to now removing NRRectL was unfeasible because 2Geom lacked an integer rectangle class, but I have recently added one. If everything goes well, I'm planning to remove NRObject as part of my GSoC project this year.
Regards, Krzysztof
It is even as I feared and expected. This Cairo renderer breaks filters which use the BackgroundImage source even more than they were already (instead of getting the correct sort of results with rendering-in-weird-blocks problems, it gets quite wrong results as well as the rendering-in-weird-blocks while editing, though not on export or full redraw).
Here is my sample case: a frosted glass type filter. An feColorMatrix on SourceGraphic and a feGaussianBlur on BackgroundImage, feComposite in of those two, feMerge that with SourceGraphic.
- SVG (white frosted box won't appear in Firefox or Chrome which don't support BackgroundImage but still try to process the filter and so mess it up): http://chrismorgan.info/temp/frost-filter.svg - PNG of correct rendering (done by cloning the image, applying the blur to it directly, and clipping it on a clone of the box as I don't have a client handy which renders BackgroundImage-utilising filters correctly - *is* there any?): http://chrismorgan.info/temp/frost-filter-nofilter.png - PNG export from some time ago with a couple of changes (less blur and white text) (note the discontinuity in the blurring in the middle - that was the subject of Bug 501873 https://bugs.launchpad.net/inkscape/+bug/501873; while editing it tended to be a lot patchier than it is in the export): http://chrismorgan.info/temp/frost-filter.png (ignore the fact that it's out horizontally by half a pixel or two - not sure why, I probably made a mistake in the parameters when exporting it back then) - PNG export (about the same when rendered during editing) from Inkscape now with Cairo rendering: http://chrismorgan.info/temp/frost-filter-cairo.png - PNG of how Eye of GNOME renders the SVG (it does the blurring in the middle rather than on the edge as Inkscape now does until you edit the filter...): http://chrismorgan.info/temp/frost-filter-eog.png
Note in the current export and the EOG export (both Cairo) the box border at the bottom is also rendered incorrectly (missing the bottom pixel), probably due to this filter (as the "how it should be rendered" is correct).
Filter treatment in general is a lot more flimsy than it used to be. When it loads this document of mine, Inkscape blurs the middle of the box rather than the edge (which doesn't match what EOG does), but when I change any value in the filter (colour matrix parameters, blur level, etc.), it changes to blurring the edge of the box and not blurring the middle, as EOG does (which still isn't right, as it should blur the whole lot). Undoing the change keeps it with this behaviour - reverting is the only way to get back to the middle-blur way. There are various other things where it just doesn't update the display properly - for example, try killing the second part of the merge by just clicking on the grab handle - the image isn't redrawn until you modify something of another type in there - e.g. change the operator in the Composite, or delete the Merge. Try playing with this document and I think you'll find quite a variety of filter support and filter editing problems. (Some of which will be bugs in Inkscape, some of which will be bugs in Cairo - but I hope that you can sort them all out nice and quickly: wouldn't that be nice!)
Another messy but curious thing: try moving the box around the document slowly (kill snapping) and the filter is rendered in all sorts of wonky ways - but at times it will be rendering it perfectly. But when you get it in a perfect position, it'll make a mess of the edges as soon as you deselect it and the bounding box and corner grips are hidden.
I tried a few other documents that I have which use other non-BackgroundImage filters and they seem to be rendering correctly, which is good.
I can also say that "average quality" rendering of Gaussian blurs with high levels of blur looks far worse than it used to (though it's definitely faster).
I can see this sort of thing becoming a bit of a headache in dealing with rendering bugs when different versions of Cairo are used. Things will be much less dependent only upon Inkscape.
Hmm. This email has grown from what I intended. Isn't that so common. I hope you get the gist of it, anyway: worse BackgroundImage rendering bugs than before, waahhh!
-- Chris
W dniu 23 czerwca 2011 14:10 użytkownik Chris Morgan <chris.morganiser@...400...> napisał:
It is even as I feared and expected. This Cairo renderer breaks filters which use the BackgroundImage source even more than they were already
I didn't put much effort into implementing correct BackgroundImage handling yet. The semantics of BackgroundImage make absolutely no sense for meat the moment. For example, background accumulation has to be explicitly enabled (there seems to be no UI for setting this besides the XML editor), and objects are rendered onto the background without filters. I got it only to the point where blend modes and other per-pixel filters worked correctly.
I can also say that "average quality" rendering of Gaussian blurs with high levels of blur looks far worse than it used to (though it's definitely faster).
I would be interested in getting a screenshot comparison. It might be related to the fact that Cairo does not properly downscale images at the moment (no supersampling).
I can see this sort of thing becoming a bit of a headache in dealing with rendering bugs when different versions of Cairo are used. Things will be much less dependent only upon Inkscape.
Filter rendering is not dependent on Cairo in any way. Only the downscaling / upscaling is, when rendering at less than 100% quality. The BackgroundImage bugs are entirely on Inkscape's side, and almost all of the problems you are seeing are due to incorrect calculation of the background area required by the filter.
Regards, Krzysztof
On Thu, 2011-06-23 at 14:28 +0200, Krzysztof Kosiński wrote:
W dniu 23 czerwca 2011 14:10 użytkownik Chris Morgan <chris.morganiser@...400...> napisał:
It is even as I feared and expected. This Cairo renderer breaks filters which use the BackgroundImage source even more than they were already
I didn't put much effort into implementing correct BackgroundImage handling yet. The semantics of BackgroundImage make absolutely no sense for meat the moment. For example, background accumulation has to be explicitly enabled (there seems to be no UI for setting this besides the XML editor), and objects are rendered onto the background without filters. I got it only to the point where blend modes and other per-pixel filters worked correctly.
There is one other way of enabling background accumulation. It is enabled if you set the "Blend Mode" to something other than normal using the Layers dialog. It will remain enabled even after resetting the blend mode back to normal. We should come up with a simpler method to enable it. The most expedient thing to do would be to enable it in the SVG root whenever the Background Image or Background Alpha is selected as a source...
Krzysztof: Congrats on merging the Cairo renderer! I've been waiting for this for a long time. I am eagerly anticipating more of your work during this years GSOC (including, perhaps, handling the filter primitive region properly?).
Tav
On 23-06-11 14:28, Krzysztof Kosiński wrote:
W dniu 23 czerwca 2011 14:10 użytkownik Chris Morgan <chris.morganiser@...400...> napisał:
It is even as I feared and expected. This Cairo renderer breaks filters which use the BackgroundImage source even more than they were already
I didn't put much effort into implementing correct BackgroundImage handling yet. The semantics of BackgroundImage make absolutely no sense for meat the moment. For example, background accumulation has to be explicitly enabled (there seems to be no UI for setting this besides the XML editor), and objects are rendered onto the background without filters. I got it only to the point where blend modes and other per-pixel filters worked correctly.
I was going to write: "As far as I can tell objects on the background image should be filtered. The spec does say something about filters and masking and such, but this just means ..." But I must confess that the explanation is a bit fuzzy to say the least, I'll ask for clarification on the svg mailing list.
As for enable-background, I think the main use case is that by explicitly setting it on an element you can avoid also taking its background into account. I can imagine this might be useful, especially when you want to make a kind of "reusable" element. That it is not enabled by default on the root element is probably to make sure that mobile applications and such don't need to invest in extra bookkeeping when it's not necessary.
I can also say that "average quality" rendering of Gaussian blurs with high levels of blur looks far worse than it used to (though it's definitely faster).
I would be interested in getting a screenshot comparison. It might be related to the fact that Cairo does not properly downscale images at the moment (no supersampling).
Is this just a flag or a limitation of Cairo?
2011/6/23 Jasper van de Gronde <th.v.d.gronde@...528...>:
I would be interested in getting a screenshot comparison. It might be related to the fact that Cairo does not properly downscale images at the moment (no supersampling).
Is this just a flag or a limitation of Cairo?
It is a limitation of Pixman (Cairo's software renderer). I roughly know how to fix this, but I think I should focus more on getting the GSoC task done.
Regards, Krzysztof
participants (11)
-
Chris Morgan -
Ivan Louette -
Jasper van de Gronde -
Joel Holdsworth -
Johan Engelen -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
LucaDC -
Tavmjong Bah -
~suv