[Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous

[Greg Zaal]

Just by the way, it's even more noticeable with GPU rendering - I've seen
it roughly 300% slower often.

"could lead to significant slowdown" sounds good to me.

On 13 November 2014 11:06, Sergey Sharybin <sergey.vfx at gmail.com> wrote:

> The issue here is that basically slowdown depends on particular hardware
> configuration, tile settings and device used to render (GPU/CPU). Meaning,
> on modern CPU i've noticed around 20% slowdown peak, which is not that bad
> as 100%. So what i'm trying to say here, is that if we'll provide
> information "up to 100% slower" it might just scary artists and they
> wouldn't use the option at all, even though for their configuration
> slowdown wouldn't be so bad.
>
> What about more neutral (in my opinion): "could lead to significant
> slowdown"?
>
> On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp <simon at fdpl.foundation>
> wrote:
>
> > Dear Renderistas,
> >
> > I only recently found out that progressive refinement in Cycles
> > rendering (which the corresponding checkbox's tooltip describes to be
> > "somewhat slower" than bucket rendering) in fact can impose performance
> > penalties of over 100% (aka the same amount of samples takes more than
> > twice as long to render).
> >
> > Now I don't know if this is just a personal flawed interpretation of the
> > english language on my part, but when reading "somewhat slower" I didn't
> > realize what I was really in for, and in retrospect I'd rather not
> > reconstruct how many days my poor laptop spent in excess to render some
> > projects I did in the past.
> >
> > I'd hereby like to propose a change of this tooltip to something less
> > ambiguous, lest anyone else falls into that same trap that I have - My
> > proposal for this would be to include actual figures describing the
> > possible speed penalty that progressive refinement can impose, that is,
> > something along the lines of "renders [a]% to [b]% slower depending on
> > the scene", where figures [a] and [b] are ideally derived from real
> > world data we gather (or already have?) about how much speed penalty
> > progressive refinement can impose in different scenes. Alternatively,
> > only stating "up to [x]% slower" would work as well I guess, as the main
> > point is to make people aware that it _can_ possibly affect render times
> > _significantly_.
> >
> > If the proposal to include figures is not agreeable for some reason, I
> > would at least ask for a more indicative wording than "somewhat slower",
> > which even after consulting multiple dictionaries I'm not sure if there
> > is an official interpretation for. (One dictionary suggests "quite" as a
> > synoym, another "slightly" ...) I'd still prefer the figures though, no
> > one looks up terms in the dictionary while using Blender and I am
> > probably not the worst offender at massacring and misunderstanding the
> > english language in the Blender community, and it doesn't get less
> > ambiguous than numbers anyway, so I say we use them here? :)
> >
> > Best,
> > Simon
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>