On 10/25/19 11:18 AM, Dick Balaska wrote:
> Speaking of POV-Ray versions, what version are y'all using?
> 
> I see several tags in git,
> v3.8.0-x.tokenizer.* (2019-01-02)
> v3.8.0-x.freetype.2 (2019-02-19)
> and
> v3.8.0-alpha.10064268 (2019-02-18)
> 
> Is the tokenizer stable?  I was waiting for clipka to merge that before 
> importing it into qtpovray, but he seems to have wandered off into RL.
> 
> Cousin Ricky says the '268 version doesn't build out of the box.
> 
> I wished we'd cut a 3.8.0 release when we were oh-so-close 2 years ago. 
> There were a bunch of new features over 3.7 and it was pretty stable. My 
> plan was to release qtpovray to the debian pool when 3.8 happened, but 
> it looks like now an actual 3.8 release is a dream.
> 
> -
> dik
> Rendered 17306265600 of 40928716800 pixels (42%)

My recollection with respect to release branches and status.

As far as I know the new tokenizer with all fixes is already in the 
current 3.8 master branch. I'm playing with one, sometimes very 
significant performance update to the function VM which is parser 
related. I'd vote for the update to be in any 3.8 release. See:

https://github.com/wfpokorny/povray/tree/performance/parseVMconstants

The freetype update has issues with inside tests which would need to be 
fixed at a minimum. I suspect there are further issues given POV-Ray 
handles loops with respect to insides differently than these are handled 
with fonts. POV-Ray using edge crossing test counts to determine 
inside-ness and fonts using clock-wise vs counter-clockwise loop 
rotation and allowing inside or outside loops to overlap without 
changing inside/outside meaning. Fonts which do this sort of same 
winding direction loop overlapping will not today work - no matter 
adopting the freetype library or not, but I think we don't know the 
frequency of fonts with overlapped loops in the additional font types 
use of freetype enables. For any merge into 3.8 and release - maybe this 
last a worry about it later thing. I don't know. If the overlaps common 
and not addressed a POV-Ray freetype enabled release might 'look' really 
buggy.

I agree with Thomas in finding the current 3.8 release quite stable. 
However, there is a performance degrade of 30-40% for generic 
architecture compiles (the usual linux package compiles). It happens 
with somewhat common use cases which are not represented well by our 
benchmark scene. In my view the degrade would ideally be addressed to at 
least some degree prior to any 3.8 release. See:

https://github.com/POV-Ray/povray/issues/363

for details.

Oh, some of the shape uv mapping documented as enabled is currently 
disabled / reverted to incorrect behavior (some earlier corrected - 
ovus) - due issues... There are days I think we should just yank all the 
3.7/3.8 in-shape uv mapping given actual use and implementation - but 
yeah, won't happen - and so it's a mess needing some straightening out 
ahead of any 3.8 release.

Certain I'm not remembering everything open... One more - given vim/gvim 
ships with all linux with 3.7 syntax support, suppose somebody should 
update it for any 3.8 release. On my list, but who knows when or if ever 
I'll get to it(1).

Bill P.

(1) - Quite a few instances in my current vim use where I don't really 
agree with the current 3.7 keyword syntax bucketing, but what's there is 
useful.

Post a reply to this message