Hi Dmitri.
Please calm down a little. Marcus is surely trying its best to keeps things
consistent and make them better.
And you are IMHO right in quite some points. Points we had not yet noticed,
as they only occur in pretty specific circumstances.
> 99% of users expect documented behavior from any kind of library.
Yes you have found a discrepancy between documentation and implementation.
And we are currently discussing, what should be fixed: docs or code.
Both sides have their pros and cons (fixing docs gives slightly faster code,
fixing the code gives more flexible behaviour and makes usage simpler for
some cases) and we will figure out a solution.
> You already told this in case of input library trying to help yourself
> to explain really strange behavior happened by using 3 functions.
I have exchanged some mails with Marcus on that topic (don't remember, if
they went through the list), and we are working on including a fix for this.
There are serious performance implications to the behaviour you expect, and
the behaviour only shows up for applications that do not drain the input
completely. Thus we will probably solve it by documenting it and introducing
a new function that allows for the behaviour you desire.
> I was amazing by targets covered by GGI and I as many other people
> expect to see this library better.
Sure. And you are helping us by finding these subtle glitches. Your comments
are valued and seriously considered and we are trying to find a decent
solution.
I suppose you could live with the one I proposed in my other mail: LibGGI
will clip correctly, even on negative values, however this might be slow on
some targets that cannot hardware-clip negative values. Could you ?
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
