Speed problem with Wine...

[Andreas Mohr Usenet 07/01]

Jeremy <nobody at nodomain.com> wrote:

> "Andreas Mohr Usenet 07/01" <xsidycvl001 at sneakemail.com> wrote in message
> news:9huiun$8sa$1 at news.BelWue.DE...

>> If you want blazingly fast Wine GDI speed, then what about writing another
>> graphics driver ? (for GGI, Berlin, ...)
>> The infrastructure already kind of exists anyway...

> I have actually looked at why wine is so slow.  I very rapidly came to the
> conclusion that it was X that was the problem.  I looked at a some of the
Bingo ! :)

> wine code and saw that it pussy-footed around X to get a result.  I have not
> devoted a lot of time to it but the issues seem to be :

> 1. X sucks when it comes to high efficiency graphics, especially bitmaps
> 2. Wine has had to do all the hard work itself - ie unaccellerated crude C
> implementations
Probably. But we should optimise as much as we can, of course.
And this is, as already stated, not really a priority at the moment, of course.

> 3. There is no way to use any hardware assistance when you have to run
> through X (unless specific GDI calls can be mapped?)
If you intend to use X graphics manipulation features, yes.
You could write a DGA driver, of course, but that's not necessarily a good
thing.

> 4. (trivially) The present release of wine doesn't allow remote X servers to
> operate, rather negating any benefit of X
Eh ?
Really ??
Why not ? So is it the current release that's broken ?
I haven't heard much about that.
So far it has been supported for ages.

>> > Secondarily, there are faults in the implementation of some GDI
> functions,
>> > especially fonts, but even simple line drawing and polyfilling is
> faulty.
>> Sure.
>> I know that e.g. controls/static.c is horribly broken.
>> I'll fix it very, very soon.
>> (it affects many programs)

> I am not talking about complex problems I am talking about things like
> polylines are too thin, or polygons don't quite fit.  I realise again, this
> is almost certainly a problem with the X interface. (fonts are another
Probably. But since even a very old thing like controls/static.c is very buggy,
some other things probably have the same kind of non-implementation.

> question.  I am seriously unimpressed with the fonts I am provided with, but
> I haven't tried to work around them yet)
Font rendering will be done by Wine via the XRender extension or so soon,
I believe. We can't rely on X11 font rendering anyway, since this doesn't
give us access to the font metrics itself.

And X11 font rendering is pretty damn incompatible at times.
That's why we need to roll our own (for local display, *not* for remote
displaying !)

>> what about getting active ON YOUR OWN ? :-)

> I'd love to.  I think wine is a good idea.  However I don't think things can
> be greatly improved in the GDI area if the X model is maintained.
Then write your own GGI driver or so, like I already said.
There's not a single excuse not to ;-)))

> I have seen a number of projects that provide fast accellerated graphics on
> *nix systems that don't use (or not wholly use) X.  they of course dispense
> with the remote capability, but as of the release I am using for wine, this
> is not an issue as it doesn't do it anyway :-)
Dito.

> Wouldn't it be great is wine could use native windows drivers for display
> cards and bypass all the X problems ?  Probably impossible or totally
> impractical, but staying with X will always result in a slower, not quite
> right solution.
I'd much rather see it use one or several of the pretty advanced
"native" Linux alternative display drivers instead of having to use X11
exclusively.
So if you want to add a driver for a different display driver system to Wine
to map the GDI stuff on that, then just go ahead ;)
(again, shouldn't be too horribly difficult, since the infrastructure is
already kind of in place)

> jeremy

> P.S. If I am annoying you, it is because I want a better outcome for
> everyone, not because it is an easy thing to complain.
*you* annoying *me* ??
I was afraid it was the other way around last time... ;)

-- 
Andreas Mohr, Renningen, Germany
In case you need to contact me after expiry of temporary email address:
my real address is (initial of first name).(last name)@mailto.de