|
|
|
|
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 17:14:31
Message: <4012ee47$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <4012eb95@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
wrote:
>> And promtly distribute binary versions without a timeout in them. No!
>
> ??!
The consequence would be users coming years later and reporting bugs in
versions they think are current. This is exactly what happened in the days
when source code was available. And it was before the WWW was around...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 17:35:06
Message: <4012f319@news.povray.org>
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> alternative would be to make the source code readable for everybody, which
> in turn would result in people make distributions based on that code,
> which is something they absolutely should not make.
>
Okay, the distribution problem is something I was not thinking about.
OTOH, if one distributes binary betas, why not source betas?
> If the next release, which will be 4.0 and is a rewrite, what point would
> there be in adding new minor patches to the official 3.x code base?
>
If 4.0 is supposed to come in several years, then "time" could be a
reason.
And as 4.0 will probably use the same numeric maths, fixing that would
IMO make sense even if minor.
> Indeed, it takes so long because quality software development takes long.
> That way we don't need to release hot fixes every other day like many
> other
> companies and projects do. And users don't have to hunt down the latest
> and greatest version every other day either.
>
No non-trivial software is completely bug-free.
So, if one waits with releases until there are really no bugs left,
one will never release it.
OTOH, if one includes patches and releases without testing, there will
be tons of bugs.
This is nothing new.
But given that problem the solution is to find a way between the two
extrema. Where the cut is to be placed depends on one's opinion.
As for me personally and considering POVRay, I'd actually prefer some
more features (now) even if they come with some more bugs. Because I
belong to those people who (potentially) fix those bugs they find.
So, I benifit from the features. And when I find a bug, oh well, then
time needs to be spent on that but _somebody_ would have to do just that
anyways sooner or later.
> Why? It is much easier to track down a bug if the source code does not
> change while you are tracking it down, so it is irrelevant if you have the
> most recent source code and can't update it or you have the release source
> code of the last official version and can't update it until you have found
> the bug.
>
...as long as I do not spend 10 hours tracking something down which
has already be fixed by someone else!
> You make the typical mistake all these "open source" proponents do, in
> assuming
> that everybody who uses a program is also able to fix it.
>
Yes, but it is enough if _one_ such person exists.
And what is the use of fubar code nobody wants to care about?
It's like cancer...
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 17:42:33
Message: <4012f4d8@news.povray.org>
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>>> And promtly distribute binary versions without a timeout in them. No!
>>
>> ??!
>
> The consequence would be users coming years later and reporting bugs in
> versions they think are current. This is exactly what happened in the
> days
> when source code was available. And it was before the WWW was around...
>
(1) That is why I always get the newest release before reporting a bug.
(2) Every bug report needs to contain a version number. And if a user
reports stoneage bugs, automatic reply would be "update your system"
There is nothing else one could do against that. I do not see any
difference, especially as under the current model, is is not only
the version "they think is the current" but it _IS_ the current,
or to express is easier:
(3) So what? The current code is year(s) old -- what makes the difference ;)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 17:51:45
Message: <4012f701$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <4012f4d8@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
wrote:
>> The consequence would be users coming years later and reporting bugs in
>> versions they think are current. This is exactly what happened in the
>> days
>> when source code was available. And it was before the WWW was around...
>>
> (1) That is why I always get the newest release before reporting a bug.
If you do it doesn't mean everybody else will. Just look at all those
Outlook Express exploiting "emails" around even after bugs had been fixed a
long time ago and there is a rather easy update feature...
> (2) Every bug report needs to contain a version number.
Tell that to users. You would be surprised how many even manage to report
the *wrong* version number...
> (3) So what? The current code is year(s) old -- what makes the difference ;)
I explained that before. That there was no 3.5.1 had no developmental
reasons. Apart from that, inn general, there is a huge difference between a
current version that has been released a year ago and a outdated long
replaced version that has been released five years ago!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> [...]
>
> If you think that I should re-implement PRTRenderer's functionality
> using plain C and use PRTImageData and PRTTileHeap for their
> purposes, I will very likely consider doing that.
PRTImageData and PRTTileHeap are both completely undocumented and they
do some really strange things - using 16 bit values for the image for
example is understandable for memory size reasons but this makes it
essentially incompatible to other patches (HDR output, post processing).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 18:11:39
Message: <4012fbaa@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> [...]
>>
>> If you think that I should re-implement PRTRenderer's functionality
>> using plain C and use PRTImageData and PRTTileHeap for their
>> purposes, I will very likely consider doing that.
>
> PRTImageData and PRTTileHeap are both completely undocumented
>
No, they are not. The header file contains a small comment on the
functionality of the methods. I normally put my docu into the header
and not into the .cpp files because when I want to use the code
lateron, I using the headers is more convenient.
But of course, more comments explaining some general ideas and
workings should be added.
> and they
> do some really strange things - using 16 bit values for the image for
> example is understandable for memory size reasons but this makes it
> essentially incompatible to other patches (HDR output, post processing).
>
Ah, you are right. In case there are other patches or parts of the code
which need the complete image in memory, one should design and implement
exactly one class which can do so if needed and can be used by all other
parts. This class should be able to handle 16 bit precision if required.
It should, however, not be the default, because the row-by-row
working of povray enables users to generate images of real large size
(6000x6000 which would use 200Mb for the PRT image buffer alone).
BTW, Since when did I have access to HDR output and post processing code?
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> [...]
>
> I consider the introduction of these two classes as good design.
Speaking of good design:
static inline void PRT_interpolate_linear(COLOUR *dest,
COLOUR *l,COLOUR *r,float p)
{
for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
{ (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p); }
}
For constructions like this you deserve to get shot.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>>and they
>>do some really strange things - using 16 bit values for the image for
>>example is understandable for memory size reasons but this makes it
>>essentially incompatible to other patches (HDR output, post processing).
>>
>
> Ah, you are right. In case there are other patches or parts of the code
> which need the complete image in memory, [...]
No, this is not about keeping the whole image, it is about keeping the
unclipped full precision color values.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 18:23:22
Message: <4012fe6a@news.povray.org>
|
|
|
| |
| |
|
|
In article <ofa### [at] tritonimagicode> , Christoph Hormann
<chr### [at] gmxde> wrote:
> Speaking of good design:
>
> static inline void PRT_interpolate_linear(COLOUR *dest,
> COLOUR *l,COLOUR *r,float p)
> {
> for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
> { (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p); }
> }
>
> For constructions like this you deserve to get shot.
Hey, that is *my* line! ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 19:38:47
Message: <40131016@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>>>and they
>>>do some really strange things - using 16 bit values for the image for
>>>example is understandable for memory size reasons but this makes it
>>>essentially incompatible to other patches (HDR output, post processing).
>>>
>> Ah, you are right. In case there are other patches or parts of the code
>> which need the complete image in memory, [...]
>
> No, this is not about keeping the whole image, it is about keeping the
> unclipped full precision color values.
>
...probably including transparency and filter which sums up to 20 bytes
per pixel which may get a problem when storing the whole image.
So, my idea would be a class which can save the complete image at
different resolutions: 8bit, 16bit, full float. If there are several
code parts in need of such a storage, the one with the highest resolution
demand will set the internally used format.
The interface would use COLOUR, but the internal data representation
would allow different formats to save memory.
(And I am not only talking about it, I would also consider writing
such a class if it is needed.)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|