> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > It makes it easier for the common code to do its work in
> logical coordinates
> > without "thinking" about device coordinates and for the
> device code to
> > work with device coordinates without thinking about logical
> coordinates.
> >
> > Sure when I started with this patch I had speed I mind but then I
> > realized that it really improved maintainance as well.
>
> I know how much you love creating new infrastructure <grin>,
:-)
> but I
> don't think it is justified in this case.
Well, since I took time writing the patch I obviously disagree. :-)
> I don't think that hiding
> the conversion behind tables of function pointers is going to help
> maintenance at all, just the opposite.
The thing is that as far as everything outside the translation layer is
concerned what is does is entirely obvious. Sure the translation layer
does some clever tricks internally with functions pointer, but it doesn't
concern the users of the translation layer. Further more what the
translation layer is doing is obvious for itself as well. There is
no strange things happening despite the many jump tables.
The common code just calls through dc->funcs using logical
coordinates just as it does now. The only extra
thing that it "needs" to think about is that if it doesn't
do optimizations for _logical_ coordinates like
"if(rect->left == rect->top) return TRUE" nobody else
is guaranteed to do it since the translation layer
might be bypassed.
Anyway this only concerns optimization not the
semantics of the code. If you don't want to optimize
the translation layer doesn't force you. The rules
is just to avoid doing work twice.
The device code has four choice: Provide a function
taking logical coordinates or a functions taking
device coordinates or provide both or provide none.
Nothing more needs to be done. The translation layer
adapts to the choices of the device code transparently
through DRIVER_Register.
There is no magical things happing at all.
If a function taking logical coordinates exists
it is called in the first place otherwise the
translation layer translates the coordinates
to device coordinates and calls the device
function.
Note that neither the common code nor the device code
has any knowledge of the existenance of the
scale to device and offset to device translations
it is something entirely internal to the translation
layer.
Since the big speed win is probably the MM_TEXT
no offset case we can dump the scale to device
and offset to device translations if you wish
it changes nothing in theory at all it just speed
things up for a few perhaps not that critical
cases.
However they doesn't cost that much to maintain,
so I think we should have them, but we can of
course add them later (post Wine 1.0) to avoid
that extra maintaince cost for now.
> The code flow is not exactly
> easy to follow right now, and we don't need to make this even worse.
Agreed, but the extra infrastructure means that we can move a lot of
code from X11 driver to the common code or the translation
layer thereby keeping the X11 driver cleaner. Any speed gains
is just secondary.
So yes I really think it will make the code easier to follow
by keep the obvious stuff like logical to device translations
out of the code that actually does something non trivial.
I think you don't see the forest because of all the trees. :-)
