abx### [at] abxartpl news:pq3m30ldlcikqc9kfo4mm1tljdiqefkqji@4ax.com

> In the next thread you said you are able to fix it. Sources of 3.5 are
> available, you claimed you are programmer. What do you need more ?

Time :) *If* no new jobs / personal life probles will apear I can start in 
about week from now.
 
> My personal opinion is that POV-Ray is not for dummies: if you type
> +W8000 +H6000 then you know it will be large image, when you type

But if You have just  photons { spacing 0.001 } it is not quite easy to 
calculate memory usage. OFcourse You can use i.e.  1.0  0.5 0.25 assuming 
it will tke (AFAIR) x2 more memory (x3 for modeia), but...

> techinics about limiting number of photons aka memory usage in
> photons{}. 

Well, right... but memory limit imho can be still usefull.
 
>> +old CPU cycle (80%, 90%) - I suggest it should also be an ini option
>> +old priority - it should be also an ini option
> where is explanation what it does ?

I ment "old" (current in 3.5 and 3.6) options.

>> - new duty cycle / priority settings - for memory, i.e. that PovRay
>> will delay for i.e. 1 second every second of memory swapping. 
> How do you want to fix memory swapping in POV-Ray for Windows if you
> do not understand that it is not a task of POV-Ray ?

Ofcourse I do understand it is not responsibility of Pov, but users will be  
heapy if it will do something extra. 
 
> IIRC current beta expires in middle of March. Until then can you write
> universal function based on 3.5 sources which recognizes than next
> line of code takes 4 mb ?

There was function linke afir POV_ALLOC that allocated memory and btw. 
calculates peek usage ustatistics. Changing it should help, like

void* pov_alloc_function( size_t size) {
  
  if ( statistics_memory_allocated += size  > max_mem_size )  
    povray_error(...)
  else malloc( ... )

Post a reply to this message