Dear Marcus
What do you mean while saying broken application:)? 99% of users expect
documented behavior from any kind of library. If you wrote in
documentation: "We do clipping" please do or you are like to be following
the Microsoft way:). The simplest choice for developers is to deny any
request saying something like that: "O that is broken application and use my
ideas not so good". 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 the question based on 3 conditions to all respectable readers of this
mail list.
1. Poll function should get latest data from device. It does not matter
that this function has actually no meaning for interrupt driven device.
2. Calling function Queued should return number of "already happened" (this
is most important) events which are in system queue.
3. And after I can read it all by using function named Read.
Dear readers, do you expect the same?
What told me you Marcus, Ok It's true my functions has different behavior
but It's just a problem for broken applications. Dear Marcus, I have enough
skills to find way around or to make it by myself if I need something what
some library does not support or support its own way. I just believe that
testing by other people anyway helps you to make your really good software
better. I was amazing by targets covered by GGI and I as many other people
expect to see this library better.
Dear Marcus please do not complain to me I just trying to make your more
serious when you telling something like that:
"When writing LibGGI applications targets are not relevant. You simply
use the API provided by LibGGI in a proper way and then don't have to
care about what targets your users may be using."
Clipping.
>>This is not defined anywhere, and I strongly believe this behaviour
>>should be documented, not "fixed".
>>The problem here is simple - the coordinate system in LibGGI ranges
>>from (0,0) to (oo,oo). Negative starting coordinates happens to work
>>when you use software clipping, but with hardware clipping and drawing
>>the results are undefined.
>>The reason this behaviour should not be changed is that for lines it
>>isn't as simple as truncating negative values to zero. I do not
>>intend to put a full software line-drawer into the matrox sublib
>>for the sole purpose of supporting broken applications.
:)
What do you offer? Is you definition of clipping limited only by positive
values? Should I make clipping for GGI functions :) by myself?
Best regards. Dmitry Semenov
P.S. If anyone want to inspect quality of my code please fell free to ask
me(if you feel ). I will send what I have made within one month after my
decision to change dos-windows to Unix:). Of course this is not bug free
and some parts are in not alfa stage yet, however as all heavy developing
software:)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marcus Sundberg
Sent: Sunday, November 07, 1999 03:45
To: [EMAIL PROTECTED]
Subject: Re: roblems over matrox fb
Andreas Beck <[EMAIL PROTECTED]> writes:
> > Sample:
> > ggiDrawLine(-10, 20, 90, 120);
> > ggiDrawBox(-10, 20, 100, 100);
> >
> > line left top end is pointed somewhere
> > Box disappeared from the screen
> >
> > I have no problem with X target. I never tested vesafb.
>
> Hmmm - might be a problem with HW-Accel. Marcus - are these HW-acceled in
> the matrox driver ?
Yes.
> If so and the problem is reproducible, could you fix
> that behaviour ? It is important, that HW-acceled functions behave exactly
> as defined by LibGGI standards.
This is not defined anywhere, and I strongly believe this behaviour
should be documented, not "fixed".
The problem here is simple - the coordinate system in LibGGI ranges
from (0,0) to (oo,oo). Negative starting coordinates happens to work
when you use software clipping, but with hardware clipping and drawing
the results are undefined.
The reason this behaviour should not be changed is that for lines it
isn't as simple as truncating negative values to zero. I do not
intend to put a full software line-drawer into the matrox sublib
for the sole purpose of supporting broken applications.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
