The quality of on-screen blur display is controlled by the Blur quality option on the new Filters tab of Inkscape Preferences (Ctrl+Shift+P). The available options range from best quality/slowest display to worst quality/fastest display, the default being in the middle between the two. Any setting except the "best quality" may introduce some rendering artefacts, especially when blurring thin strokes; on the other hand, the "best quality" setting may make Inkscape extremely slow at high zooms. These settings only affect the screen display of blurred objects; bitmap export always uses the best quality.
holy crap this is awesome! I should start expecting this kind of thing from you bulia because it happens so often.. Thank you very much.
just played with it a bit . i think i prefer second lowest quality setting even on faster computers.. still i think average should be the default . wow i love it !!!
On Mon, 2006-10-09 at 05:25 -0300, bulia byak wrote:
The quality of on-screen blur display is controlled by the Blur quality option on the new Filters tab of Inkscape Preferences (Ctrl+Shift+P). The available options range from best quality/slowest display to worst quality/fastest display, the default being in the middle between the two. Any setting except the "best quality" may introduce some rendering artefacts, especially when blurring thin strokes; on the other hand, the "best quality" setting may make Inkscape extremely slow at high zooms. These settings only affect the screen display of blurred objects; bitmap export always uses the best quality.
Er, so what does this slider control, exactly? Supersampling for blur? Depending on how this is being implemented, we might have standards conformance problems when rendering...
-mental
On 10/11/06, MenTaLguY <mental@...3...> wrote:
Er, so what does this slider control, exactly?
Not a slider - it's a set of radio buttons.
Supersampling for blur?
Yes.
Depending on how this is being implemented, we might have standards conformance problems when rendering...
I don't think so. No more "conformance problems" than with Outline mode, anyway. Unlike Outline, it looks reasonably blur-like even at lowest settings.
On Wed, 2006-10-11 at 15:09 -0300, bulia byak wrote:
On 10/11/06, MenTaLguY <mental@...3...> wrote:
Er, so what does this slider control, exactly?
Not a slider - it's a set of radio buttons.
Supersampling for blur?
Yes.
Depending on how this is being implemented, we might have standards conformance problems when rendering...
I don't think so. No more "conformance problems" than with Outline mode, anyway. Unlike Outline, it looks reasonably blur-like even at lowest settings.
Heya, when you really max out the blur, is it a bug that the blur is restricted to the selection bounding box around the blurred object? That seems like a bug to me, but it might be that way because of computation time. I think that adobe does the same thing...
What do you all think?
Jon
On 10/11/06, Jon Phillips <jon@...235...> wrote:
Heya, when you really max out the blur, is it a bug that the blur is restricted to the selection bounding box around the blurred object?
Not a bug - just not implemented yet. Per the spec, by default the blur margins are 10% of the object size. There's an attribute which allows to enlarge that margin, but we don't set it yet (but it's planned).
On Wed, 11 Oct 2006, bulia byak wrote:
Date: Wed, 11 Oct 2006 15:09:53 -0300 From: bulia byak <buliabyak@...400...> To: MenTaLguY <mental@...3...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: blur quality/speed settings
On 10/11/06, MenTaLguY <mental@...3...> wrote:
Er, so what does this slider control, exactly?
Not a slider - it's a set of radio buttons.
This seems like a very fine grained level of control when two or three levels might be enough for 99% of users.
You might be interested to take a look at Macromedia Freehand. It has a menu item for "Fast Mode" and along side that another menu item for "KeyLine Mode" the combination of both results in much faster rendering. Fast mode reduce the amount blending to very low levels. Keyline works very much like Wireframe mode in Inkscape but as far as I can tell from the documentation it does leave out some lines for faster rendering (hence "Key line"). Maybe you dont want to take the same approach but I do hope it is of interest to know about it.
It does seem like there will be times where accuracy gets traded off against speed but if I recall conversations correctly Inkscape developer go for accuracy. Some kind of quality/speed control to help balance that out for certain users makes a lot of sense so I'm glad to see this being developed.
I don't think so. No more "conformance problems" than with Outline mode, anyway. Unlike Outline, it looks reasonably blur-like even at lowest settings.
I really hope the name will be changed from Outline mode, since it was so often describe as Wireframe mode. Before anyone asks I did file a request a while back: http://sourceforge.net/tracker/index.php?func=detail&aid=1538427&gro...
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Wed, 2006-10-11 at 15:09 -0300, bulia byak wrote:
Depending on how this is being implemented, we might have standards conformance problems when rendering...
I don't think so. No more "conformance problems" than with Outline mode, anyway. Unlike Outline, it looks reasonably blur-like even at lowest settings.
Well, I'm thinking specifically of the case where the author (for whatever reason -- artistic effect?) provides an explicit filterRes. We need to make sure that can take precedence.
Aside from that, we probably also need to think about making the various rendering quality settings settable separately for editing and for bitmap export.
-mental
On 10/11/06, MenTaLguY <mental@...3...> wrote:
Well, I'm thinking specifically of the case where the author (for whatever reason -- artistic effect?) provides an explicit filterRes. We need to make sure that can take precedence.
Yes - though right now we just ignore filterRes and always render it at the current zoom's resolution. And when we use supersampling, the results are smoothly interpolated, so they don't look "pixelated" as filterRes would imply. So it seems to me that filterRes should be orthogonal to our own supersampling+interpolation rendering hack (used for display only).
Aside from that, we probably also need to think about making the various rendering quality settings settable separately for editing and for bitmap export.
Currently bitmap export uses highest quality. Perhaps the only reason why anyone would want to change that is that it may become very slow at high resolutions. So if anyone is using Inkscape for commandline bitmap export in time-critical applications (e.g. on a web server), and if you run into slowness issues, let me know and I'll add a quality setting for bitmap export.
On Thu, 2006-10-12 at 00:13 -0300, bulia byak wrote:
On 10/11/06, MenTaLguY <mental@...3...> wrote:
Well, I'm thinking specifically of the case where the author (for whatever reason -- artistic effect?) provides an explicit filterRes. We need to make sure that can take precedence.
Yes - though right now we just ignore filterRes and always render it at the current zoom's resolution. And when we use supersampling, the results are smoothly interpolated, so they don't look "pixelated" as filterRes would imply. So it seems to me that filterRes should be orthogonal to our own supersampling+interpolation rendering hack (used for display only).
Aside from that, we probably also need to think about making the various rendering quality settings settable separately for editing and for bitmap export.
Currently bitmap export uses highest quality. Perhaps the only reason why anyone would want to change that is that it may become very slow at high resolutions. So if anyone is using Inkscape for commandline bitmap export in time-critical applications (e.g. on a web server), and if you run into slowness issues, let me know and I'll add a quality setting for bitmap export.
I think this would be a great idea, as Open Clip Art Library uses Inkscape to make thumbnails. Yes, hopefully it can be abstracted for other filetypes as well (this type of quality setting, jpeg, gif, etc).
Jon
On 10/12/06, Jon Phillips <jon@...235...> wrote:
I think this would be a great idea, as Open Clip Art Library uses Inkscape to make thumbnails.
OK, so _if_ you really run into speed issues there, just let me know :)
On Thu, 2006-10-12 at 03:04 -0300, bulia byak wrote:
On 10/12/06, Jon Phillips <jon@...235...> wrote:
I think this would be a great idea, as Open Clip Art Library uses Inkscape to make thumbnails.
OK, so _if_ you really run into speed issues there, just let me know :)
Yes, agreed. :)
-mental
At some zoom level in one cas I obtained a saturation (overlimit value ?) effect with very low qualiting setting for blur :
http://popolon.free.fr/Bug_de_loeuf.png
The original SVGZ is here with a png of the working example :
On 10/11/06, Popolon <popolon@...1497...> wrote:
At some zoom level in one cas I obtained a saturation (overlimit value ?) effect with very low qualiting setting for blur :
http://popolon.free.fr/Bug_de_loeuf.png
The original SVGZ is here with a png of the working example :
Thanks for reporting - I could reproduce it. Would you please submit a bug with this file and the exact zoom and quality setting? I will look into it when I have time.
By the way your file failed to load because of invalid chars in the metadata:
Oeuf.svg:104: parser error : internal error dc:titleOeuf▒</dc:title> ^ Oeuf.svg:104: parser error : Extra content at the end of the document dc:titleOeuf▒</dc:title> ^
Did you use Inkscape to fill in the metadata? If so, we have another bug - the metadata written to the file is apparently not UTF8-encoded as it should. Please file that as a separate bug.
bulia byak wrote:
By the way your file failed to load because of invalid chars in the metadata:
Oeuf.svg:104: parser error : internal error dc:titleOeuf▒</dc:title> ^ Oeuf.svg:104: parser error : Extra content at the end of the document dc:titleOeuf▒</dc:title> ^
Did you use Inkscape to fill in the metadata? If so, we have another bug - the metadata written to the file is apparently not UTF8-encoded as it should. Please file that as a separate bug.
https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1575829...
participants (6)
-
Alan Horkan -
Andy Fitzsimon -
bulia byak -
Jon Phillips -
MenTaLguY -
Popolon