> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > So the few exception should be marked somehow like
> > void FOODRV_DEV_Bar(void)
> > or
> > void FOODRV_LOG_Bar(void)
>
> Great, let's obfuscate the function names to try to explain what the
> code is doing...
I have said it before and I say it again. Most (all?) will either
have functions taking logical coordinates (metafiles and friend)
or functions taking device coordinate (X11 and friends) not both.
>From your comment I take it that the normal case should be without
prefix. OK, fine by me I don't care that much.
Sure the X11 will during the transition phase have both and might
retain some of the function taking logical coordinates for
performance reasons. They need to be clearly marked of course
but they will not be many if any at all.
As for the obfuscation. As I have said there are two and only two
kinds of functions. Functions taking logical coordninates and functions
taking device coordinates. Device are of two types as well, devices
taking mainly logical coordinates and device taking mainly device
coorinates.
Once somebody knows that, only an utter and complete idiot would
fail to realize that:
1. FOODRV_DEV_Bar means device coordinates
2. FOODRV_LOG_Bar means logical coordinates
3. FOODRV_Bar mean default coordinates for device
OK, there are function that doesn't take any kind of coordinates
at all but you really can't go wrong with these kind of functions
anyway.
> then of course some function gets moved to another
> table without being renamed and the situation is even worse than
> before.
You are joking right. How often do you think that will happend?
Once in a million? People submitting patches are not incompetent
and the person that applies them (read: you) are not that either.
OK. That said we probably should rename the X11DRV functions
that takes logical coordinates to X11DRV_LOG temporarily and
rename them back when each is converted just in case.
At the very least it gives something to "grep" on while
searching for functions to convert. :-)
> I really don't see the point, you are inventing more and more complex
> mechanisms and conventions to fix what is a non-existent issue.
Your honour, I object, it is not an non-existent issue. See below.
> Right
> now graphics driver always take logical coordinates and do the
> conversion,
Yes and that is fundentally wrong, see below.
> it works,
Sure. Microsoft Windows works most of the time to,
I don't reboot that often (only twice or thrice a week).
OK, sorry that was a cheap shot. :-)
> it's clear from reading the code what is
> happening,
Yes, but it will be equally clear with my solution.
> and I don't see any reason to change it.
I have said it before and I say it again, the device
driver interface is wrongly designed since fails to
realize that there are two fundamentally different
kinds of drivers. This is the _teoretical_ reason.
The _practical_ reasons are the following
1. It means that translation will take place almost exclusively
in the translation layer. This means less code in the device
drivers and increased sharing of code between the different
drivers. This means less memory usage and easier maintaince
when almost every translation is done in one place.
2. The separation of device and logical interfaces will allow
MM_TEXT with no offset to bypass the translation layer
completely. This means it will be faster for applications
that cares about speed.
3. It will allow having special handling for the different
kind of mappings (world, scale, offset) so each case
can have special optimizations. This will be especially
important when we fully support world transform since
they use floats while the normal code only needs integer.
99.99% of all applications doesn't use world transform
so I see no reason they should pay the price for that.
Beside Wine (and especially WineLib) might be used on
machines that doesn't have (or emulate) floats so it
lessen portabillity.
4. Note that can do 3 optionally in assembler in order
to even more increase speed on different platforms.
Doing this is quite easy just have for example
scl2dev_i386.c and a scl2dev_i386.h with
__HAVE_ARCH_SCL2DEV_FOO and friend that mark which
functions that have an arch specific implementation.
In short, I think there are plenty of reasons both to do
things differently than we do now as well as reasons to
do things like I have done in my patch.
Sure I'm open to suggestions but claiming that there is no
reason for any changes is very strange indeed. I'm telling
you the device driver interface Wine currenly uses is _broken_
and my new design will fix many of the problems and as well
as a side effect making things faster and more maintainable.
So far you have only pointed out problems that I already
have thought of but didn't point out myself since they
have IMHO obvious solutions.
So please explain
1. What you _really_ think is the problem with my patch?
2. Why the current design is good enough and if not
how you wish to solve the problems meantioned above?
PS. Do not claim that lack of optimizations is not
an issue. We have all seen the sucky benchmarks.
Sure blaiming X is convienient but it isn't the
whole story.
