> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > Sure but the point is that there are one kind of drivers that
> > do nothing (metafile) and one kind that do software conversions.
> >
> > That _is_ the fundamental difference.
>
> That's a completely artificial distinction. You may just as well say
> that some drivers use Xlib and some don't, so that we need two
> different interfaces.
Bad example, Microsoft Windows have no concept of Xlib but it
has one about logical and device coordinates. But never mind,
I get the point I just don't agree.
> The whole point of the driver interface is that
> it is generic: all drivers can be implemented based on the same
> interface, and that is a *good* thing.
But the interface is the same (DC_FUNCTIONS is both cases)
it is just that coordinates have been mapped in one of the
cases so the driver doesn't have to do it.
> Yes there is some code
> duplication when two drivers do similar things; that's not a
> problem. If the shared code gets large it can be moved to a common
> function, but it doesn't have to be part of the interface.
In something meaning it is moved a common function in my patch,
it is just that I do it transparently. You want to do it explicitly,
this will work of course, but I don't see any reason to bloat the
code with that.
And the interface _is_ the same except for the mapping of coordinates.
It is because it is the same that the translation layer can be
bypassed when we have MM_TEXT with no offset.
> > You haven't really said why except for pointing out some potential
> > problem that have obvious solutions.
> >
> > I think this is the main point of our disagreement.
> > However I can't argue against "I strongly disagree with"
> > without good explaination.
>
> If you don't agree that adding new artificial interfaces and strange
> naming conventions makes the code less maintainable I'm afraid I can't
> explain much more. You'll just have to take my word for it ;-)
I agree that adding artical interfaces is not always good (perhaps even
often bad) and strange naming convention is unfortunate but IMHO
is most cases a very small price to pay.
However I do not agree with the classification of as artical interface.
That is probably the main disagreement. I don't know what to say.
>From a teoretical point of view all distinctions are artifical.
So a limit must be drawn at some more or less arbitrary point.
As far I'm concern the different types in this case exist in
real life and therefore the distinction is not artificial.
It is like the distinction between a multilingual website and
a website with only one language. If I go to http://www.debian.org
I get a swedish translation if you go to it you probaly get
an english or french or german or whatever translation.
What you are arguing against is basicly that since I know english
I can just as well do the translation myself since the boundaries
between the languages are artifical. But why should I bother
when I can use the Debian "language translation layer". :-)
> > I ask again:
> > How are you going to support world transform
> > which uses float without having normal application
> > paying the price of this? Specifially be able
> > to run without FPU.
> >
> > Are you going to bloat the X11 driver with that code?
> > It will probably look really nice and cosy. NOT!
>
> You put that in LPtoDP and friends, which the drivers then use as they
> need it.
Thats true, it will work of course.
It will be a little better but at
the cost of an even slower benchmark.
Congratulations. :-)
> No code duplication,
So if you use DPtoLP in one driver every driver
will use it. Magic. :-)
Seriously, I understand what you mean, but the fact remains
that all driver of the same type to will do (almost?) exactly
the same conversion. That _is_ code duplication as well,
not equal bad but not good nether the less.
> and no new complicated interface.
But it really isn't that complicated. You don't really
have to think about much at all when maintaining the code.
You need to know whether a driver is of type logical or
of type device. No more, no less.
> If you
> absolutely want a jump table you can put one in there, so that LPtoDP
> branches to different functions depending on the current transform and
> we don't do the floating point stuff when not needed.
Whether we do this or not is totally ortogonal with my solution.
We should do it IMHO but that is a completely different question.
