Hi everyone,
We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows.
That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes.
-Gav
Hï Gavriel,
Could you provide 2 screenshots please - one with this SDL driver and the same - without SDL please?
Thanks, Hetz
On Sunday 27 January 2002 06:49, Gavriel State wrote:
Hi everyone,
We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows.
That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes.
-Gav
There would be no appreciable differences. As I said, this was mostly something we were just toying with.
-Gav
Hetz Ben Hamo wrote:
Hï Gavriel,
Could you provide 2 screenshots please - one with this SDL driver and the same - without SDL please?
Thanks, Hetz
On Sunday 27 January 2002 06:49, Gavriel State wrote:
Hi everyone,
We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows.
That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes.
-Gav
On 2002.01.28 02:12 Gavriel State wrote:
There would be no appreciable differences. As I said, this was mostly something we were just toying with.
-Gav
Very interesting. I was considering making an RFB (the VNC protocol) backend for Wine for about the same reason. That is that the only really decent driver is X11 right now since ttydrv is fairly useless.
Hmm, maybe I should actually do that. As an added bonus since VNC is just basically a generic framebuffer it would allow a fairly easy port to another generic framebuffer interface such as LinuxFB (or whatever the new hot-shit FB project for Linux is these days).
-Dave
Hmm, maybe I should actually do that. As an added bonus since VNC is just basically a generic framebuffer it would allow a fairly easy port to another generic framebuffer interface such as LinuxFB (or whatever the new hot-shit FB project for Linux is these days).
Hmm, do I hear embedded devices with wine? :)
Hetz
--- Hetz Ben Hamo hetz@kde.org wrote:
Hmm, maybe I should actually do that. As an added
bonus since VNC is just
basically a generic framebuffer it would allow a
fairly easy port to
another generic framebuffer interface such as
LinuxFB (or whatever the new
hot-shit FB project for Linux is these days).
Hmm, do I hear embedded devices with wine? :)
Hetz
You might want to take a look at microwindows if you want GDI/framebuffer
__________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
David Elliott wrote:
On 2002.01.28 02:12 Gavriel State wrote:
There would be no appreciable differences. As I said, this was mostly something we were just toying with.
Very interesting. I was considering making an RFB (the VNC protocol) backend for Wine for about the same reason. That is that the only really decent driver is X11 right now since ttydrv is fairly useless.
Hmm, maybe I should actually do that. As an added bonus since VNC is just basically a generic framebuffer it would allow a fairly easy port to another generic framebuffer interface such as LinuxFB (or whatever the new hot-shit FB project for Linux is these days).
Well, the sdldrv is a long way from being capable of that kind of thing. 8-)
The big thing that's missing is a real GDI renderer. It's great to have something that can kind-of do a bitblt, but if you want to have windows and menus and such on the screen, a real renderer is needed. Aside from BitBlit-ing, it would need to handle polygons, brushes, pens, clipping, and most painfully, text. It's possible that some of Huw's recent work might help there, but I'm not sure - I think that XRender actually requires X...
Now, the interesting thing is this: Once we have a GDI renderer, we can eliminate a *huge* amount of DIBSection cruft from the X11 driver. Currently Wine goes through astounding manipulations to get X to draw things for us when we should be doing it ourselves. This is very slow, and affects more apps than you might think (ie: WordPerfect).
We actually have a co-op student (Hi Jonathan!) who we've asked to look into this a bit. He's quite new to Wine, and has some other duties as well, but I'm sure that he would be interested in sharing the work. 8-)
-Gav
On Mon, 28 Jan 2002, Gavriel State wrote:
Now, the interesting thing is this: Once we have a GDI renderer, we can eliminate a *huge* amount of DIBSection cruft from the X11 driver. Currently Wine goes through astounding manipulations to get X to draw things for us when we should be doing it ourselves. This is very slow, and affects more apps than you might think (ie: WordPerfect).
I know that we've had our share of problems from the lack of such renderer. Currently, we ask X to do the work for us, as you describe. Now, XFree86 is licensed under a Wine-compatible license. Why can't we simply get the XFree86 code directly into Wine, to get our own renderer?
-- Dimi.
On Mon, Jan 28, 2002 at 11:21:20PM -0500, Dimitrie O. Paun wrote:
On Mon, 28 Jan 2002, Gavriel State wrote:
Now, the interesting thing is this: Once we have a GDI renderer, we can eliminate a *huge* amount of DIBSection cruft from the X11 driver. Currently Wine goes through astounding manipulations to get X to draw things for us when we should be doing it ourselves. This is very slow, and affects more apps than you might think (ie: WordPerfect).
I know that we've had our share of problems from the lack of such renderer. Currently, we ask X to do the work for us, as you describe. Now, XFree86 is licensed under a Wine-compatible license. Why can't we simply get the XFree86 code directly into Wine, to get our own renderer?
NOW is the time to sync with ReactOS, if not big duplicate effort will occur.
regards, Jakob
-
David Elliott -
Dimitrie O. Paun -
Gavriel State -
Hetz Ben Hamo -
Jakob Eriksson -
Steven Edwards