Documentation volunteer(s) needed

[Alexandre Julliard]

Folks,

As most of you probably know (at least those of you who managed to get
out of bed in time for my keynote ;-) we are supposed to release 0.9
real soon now.  We do have one remaining issue: the documentation
needs some major work. Not every bit of it is critical for the
release, but we need to fix at least the User's Guide to reflect the
recent configuration changes. Would anybody be interested in helping
with that?

[Holly Bostick]

Alexandre Julliard schreef:
> Folks,
>
> As most of you probably know (at least those of you who managed to get
> out of bed in time for my keynote ;-) we are supposed to release 0.9
> real soon now.  We do have one remaining issue: the documentation
> needs some major work. Not every bit of it is critical for the
> release, but we need to fix at least the User's Guide to reflect the
> recent configuration changes. Would anybody be interested in helping
> with that?

YES!!! Where do I sign up?

Holly

[Brian Vincent]

On 9/20/05, Holly Bostick  wrote:
> YES!!! Where do I sign up?

Hopefully I can make this easier on someone.  Also, I'm cc'ing Scott
Ritchie since he mentioned at one point he was interested in this.

The docs now live in a separate CVS tree, I don't have the details for
that.  After grabbing them from CVS, you'll want to make sure you have
the docbook tools available for compiling.  In the docs directory you
can just do a "make html" or some such in order to generate nicely
viewable material to help with editing.

I started in on this about a year ago and there's a pretty good
outline to work from.  Some of the actual content is just plain wrong
now, but it's probably about 90% accurate.  There have been changes
the the DLL Overrides and Drive Settings part of Winecfg.  I'd also
consider this stuff to be a little light on the configuration side. 
For example, to configure just application settings you need to add an
app on the first tab of winecfg and then make the overrides on the
second tab.  I don't think this discusses how that per-app stuff is
done (it also affects Graphics.)

Last year I sent this to wine-devel talking about it:

-------

For now, the biggest changes can be found in configuring.sgml  (which
translates into the "Configuring Wine" part of the guide.)  A diff is
available here:

http://www.theshell.com/~vinn/wine-user-guide.diff

However, this stuff is best looked at as a side-by-side comparison with
the existing docs.  You can find that here:

http://www.theshell.com/~vinn/wine-user-guide.html

(Not having looked at Mike's recent patches, I'm sure this will soon be out
of date.  Things like drive detection are missing.  There's also parts that
I left undone: such as the printing config, an appendix listing reg keys would
be nice once we know what they all are.  Other parts probably need a
better explanation, such as font configuration.  Anything you notice missing
is probably worth telling me about, though it won't be hard to find lots of
mistakes.)

One of the big goals of all this is to reduce the amount of documentation
and outdated stuff.  Therefore, registry.sgml, printing.sgml, and fonts.sgml
have been somewhat merged into configuring.sgml.  fonts.sgml contained a
lot of outdated info in it that probably caused more confusion than helped.

Going forward, we have a lot of documentation in the User Guide about
downloading Wine, compiling Wine, CVS, etc; mostly stuff that's already
duplicated in some form or another on the web site.  I'd like to see as
much stuff like that removed from the User Guide as possible, we can
simply refer people to WineHQ for more info.  (I think the reason for the
duplication is that the website docs simply didn't exist when the User
Guide was written, now the website has superceded the User Guide.)
When it's all said and done we should be left with the following sections:
 - Introduction
 - Configuration
 - Running
 - Troubleshooting

--------

There's enough material on this topic to practically write a book. 
Someone should think about that.

-Brian

[Holly Bostick]

Brian Vincent schreef:
> Hopefully I can make this easier on someone.  Also, I'm cc'ing Scott 
> Ritchie since he mentioned at one point he was interested in this.
>
> The docs now live in a separate CVS tree, I don't have the details
> for that.  After grabbing them from CVS, you'll want to make sure you
> have the docbook tools available for compiling.  In the docs
> directory you can just do a "make html" or some such in order to
> generate nicely viewable material to help with editing.
>
> I started in on this about a year ago and there's a pretty good 
> outline to work from.  Some of the actual content is just plain wrong
>  now, but it's probably about 90% accurate.  There have been changes 
> the the DLL Overrides and Drive Settings part of Winecfg.  I'd also 
> consider this stuff to be a little light on the configuration side. 
> For example, to configure just application settings you need to add
> an app on the first tab of winecfg and then make the overrides on the
>  second tab.  I don't think this discusses how that per-app stuff is 
> done (it also affects Graphics.)

One other question in this regard; I'm currently running 20050830. Do I
need to compile from CVS to get a more accurate picture of the current
state of what I'm documenting, or is the current release (naturally I'll
update to the September release as soon as I see it) 'close enough'?
> <snip of very useful current status information>
>
> Going forward, we have a lot of documentation in the User Guide about
>  downloading Wine, compiling Wine, CVS, etc; mostly stuff that's
> already duplicated in some form or another on the web site.  I'd like
> to see as much stuff like that removed from the User Guide as
> possible, we can simply refer people to WineHQ for more info.  (I
> think the reason for the duplication is that the website docs simply
> didn't exist when the User Guide was written, now the website has
> superceded the User Guide.) When it's all said and done we should be
> left with the following sections: - Introduction - Configuration -
> Running - Troubleshooting

OK, that's at least an outline of what you/we aim to achieve which is
(very) good, of course. Nothing more to say until I've looked at the
current material, but I can see the benefits of aiming for simplicity
and clarity.

I hope the release is stable enough to support these goals (I have faith).

Oh yeah, another question-- are we making provision for 'special
circumstances'? I've got an ATI card, which makes me sensitive to such
things, since the ATI drivers fail to do many things that they should,
and often additional provisions need to be made specifically to get an
app or game to run with the stupid fglrx drivers, where no such config
workarounds need to be used with nVidia cards, or so I've heard. Or does
that just fall under 'Troubleshooting'? Or does Wine not need such
workarounds at all (unlike Cedega)? My Wine install seems to be acting a
bit flakey atm, and I'm not sure why, so I haven't gotten as far with my
current project of documenting what works where (Wine vs. Cedega) as I
would like, and it makes it hard to be sure whether something that works
under Cedega but not under Wine is because I can configure Cedega to
work around some ATI problems, whereas I can't with Wine, or whether
it's because my Wine install is acting flakey, or because Wine is kinda
broke atm in some ways.
> There's enough material on this topic to practically write a book. 
> Someone should think about that.

Didn't you get a replacement co-author yet?? Amazing, if true. But
that's another discussion :) .

Thanks for the info; I'll get over to the documentation CVS later
tonight or early tomorrow.

Holly

[Tom Wickline]

On 9/20/05, Holly Bostick  wrote:
> Oh yeah, another question-- are we making provision for 'special
> circumstances'? I've got an ATI card, which makes me sensitive to such
> things, since the ATI drivers fail to do many things that they should,
> and often additional provisions need to be made specifically to get an
> app or game to run with the stupid fglrx drivers, where no such config
> workarounds need to be used with nVidia cards, or so I've heard. Or does
> that just fall under 'Troubleshooting'? Or does Wine not need such
> workarounds at all (unlike Cedega)?

IMHO.... Cedega should not even remotely be in the equation, the
documentation is about Wine and only Wine. The folks at TG can write
docs for Cedega as CW writes docs for CrossOver. So please don't
reference Cedega in the docs.

Tom
> Holly

[Holly Bostick]

Tom Wickline schreef:
> On 9/20/05, Holly Bostick  wrote:
> > Oh yeah, another question-- are we making provision for 'special 
> > circumstances'? I've got an ATI card, which makes me sensitive to 
> > such things, since the ATI drivers fail to do many things that they
> >  should, and often additional provisions need to be made 
> > specifically to get an app or game to run with the stupid fglrx 
> > drivers, where no such config workarounds need to be used with 
> > nVidia cards, or so I've heard. Or does that just fall under 
> > 'Troubleshooting'? Or does Wine not need such workarounds at all 
> > (unlike Cedega)?
>
> IMHO.... Cedega should not even remotely be in the equation, the 
> documentation is about Wine and only Wine. The folks at TG can write 
> docs for Cedega as CW writes docs for CrossOver. So please don't 
> reference Cedega in the docs.
>
> Tom

No, I had no intention of doing so, and the reference to Cedega was
peripheral to my question. It is only referenced at all because that is
how I learn to understand things, by triangulation between points.

But in any case, I'm having another problem somewhat more relevant-- the
docs don't compile as html for me:

./configure; make
checking whether make sets $(MAKE)... yes
checking for docbook2html... docbook2html
checking for docbook2pdf... docbook2pdf
checking for docbook2ps... docbook2ps
checking for docbook2txt... docbook2txt
checking for nsgmls... nsgmls
configure: creating ./config.status
config.status: creating Make.rules
config.status: creating Makefile
config.status: creating en/Makefile
config.status: creating fr/Makefile

Configure finished.  Do 'make' to compile the documentation.

make[1]: Entering directory `/usr/local/src/docs/en'
docbook2html -u winedev-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/winedev-guide.sgml
Done.
docbook2html -u wineusr-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/wineusr-guide.sgml
Done.
docbook2html -u winelib-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/winelib-guide.sgml
Done.
docbook2html -u wine-faq.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/wine-faq.sgml
jade:/usr/local/src/docs/en/wine-faq.sgml:1611:13:E: document type does
not allow element "PARA" here; missing one of "FOOTNOTE", "MSGTEXT",
"CAUTION", "IMPORTANT", "NOTE", "TIP", "WARNING", "BLOCKQUOTE",
"INFORMALEXAMPLE" start-tag
jade:/usr/local/src/docs/en/wine-faq.sgml:1616:14:E: end tag for "PARA"
omitted, but OMITTAG NO was specified
jade:/usr/local/src/docs/en/wine-faq.sgml:1602:8: start tag was here
jade:/usr/local/src/docs/en/wine-faq.sgml:1737:21:E: non SGML character
number 132
jade:/usr/local/src/docs/en/wine-faq.sgml:1738:84:E: non SGML character
number 132
make[1]: *** [wine-faq.html] Fout 8
make[1]: Leaving directory `/usr/local/src/docs/en'
make: *** [en] Fout 2

I don't have time to look at the files right now, but from what Brian
said before, it's not strictly necessary to compile them to use/modify
them. Is that correct, or should I be disturbed by this? If I should be
disturbed, can someone point me to a quick fix?

Holly

[Dimi Paun]

On Tue, 2005-09-20 at 23:30 +0200, Holly Bostick wrote:
> But in any case, I'm having another problem somewhat more relevant--
> the docs don't compile as html for me:

It should be fixed now, just get the latest version.

[Holly Bostick]

Dimi Paun schreef:
> On Tue, 2005-09-20 at 23:30 +0200, Holly Bostick wrote:
> > But in any case, I'm having another problem somewhat more
> > relevant-- the docs don't compile as html for me:
>
> It should be fixed now, just get the latest version.

Just a quick note-- I deleted the previous docs source dir, checked out
the current one an hour ago.

I will first say that I did get the docs to compile (so now I can read
and edit them), *but* I had to compile all formats to do so.

I was unable to compile just the html (which would have been preferable
to me, since I have no use for .ps or.pdf files), because make html
consistently failed with the following error:

./configure; make html
checking whether make sets $(MAKE)... yes
checking for docbook2html... docbook2html
checking for docbook2pdf... docbook2pdf
checking for docbook2ps... docbook2ps
checking for docbook2txt... docbook2txt
checking for nsgmls... nsgmls
configure: creating ./config.status
config.status: creating Make.rules
config.status: creating Makefile
config.status: creating en/Makefile
config.status: creating fr/Makefile

Configure finished.  Do 'make' to compile the documentation.

make[1]: Entering directory `/usr/local/src/docs/en'
docbook2html -u winedev-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/winedev-guide.sgml
Done.
docbook2html -u wineusr-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/wineusr-guide.sgml
Done.
docbook2html -u winelib-guide.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/winelib-guide.sgml
Done.
docbook2html -u wine-faq.sgml
Using catalogs: /etc/sgml/sgml-docbook-3.1.cat
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html
Working on: /usr/local/src/docs/en/wine-faq.sgml
Done.
make[1]: Leaving directory `/usr/local/src/docs/en'
make[1]: Entering directory `/usr/local/src/docs/fr'
PERLLIB=../po4a/lib perl ../po4a/po4a-translate -v -f sgml -m
../en/wineusr-guide.sgml -p ./wineusr-guide.po -l wineusr-guide.sgml -k 1
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: msgid skipped to help translators (contains only tags)
po4a::sgml: nsgmls is missing or non-functional
make[1]: *** [wineusr-guide.sgml] Fout 2
make[1]: Leaving directory `/usr/local/src/docs/fr'
make: *** [fr/__html__] Fout 2

I also tried make html en (since I have no use for the French version
either); that also failed with the same error, but that may not be a
valid command -- the README doesn't really say that I can combine the
<type> and <lang> switches, but I thought I'd try.

I already had docbook-sgml-utils, opensp, openjade, and tetex installed,
so I as far as the README goes, I had all the dependencies. So I
additionally installed docbook-sgml and sgmltools-lite just to cover any
possible missed bases), and then thought to just run make en, which
succeeded.

So I have no idea whether installing docbook-sgml and sgmltools-lite had
any effect, or whether make html is just not properly working for some
reason, but I thought I should report the experience.

Holly

[Dimi Paun]

From: "Holly Bostick"
> I will first say that I did get the docs to compile (so now I can read
> and edit them), *but* I had to compile all formats to do so.

Sorry about that, the French version is still not up to par.
> I also tried make html en (since I have no use for the French version
> either); that also failed with the same error, but that may not be a
> valid command -- the README doesn't really say that I can combine the
> <type> and <lang> switches, but I thought I'd try.

You just have to change dir to the en/ dir:
   cd en; make html
That would do what you want to accomplish.
> So I have no idea whether installing docbook-sgml and sgmltools-lite had
> any effect, or whether make html is just not properly working for some
> reason, but I thought I should report the experience.

Thank you! Let's hope someone fixes the French docs building issues
(hint, hint! :)).

[Stefan Dösinger]

Hello,
> Oh yeah, another question-- are we making provision for 'special
> circumstances'? I've got an ATI card, which makes me sensitive to such
> things, since the ATI drivers fail to do many things that they should,
> and often additional provisions need to be made specifically to get an
> app or game to run with the stupid fglrx drivers, where no such config
> workarounds need to be used with nVidia cards, or so I've heard. Or does
> that just fall under 'Troubleshooting'? Or does Wine not need such
> workarounds at all (unlike Cedega)?

There are for sure some cases where fglrx-specific problems exist. I am 
hunting two problems with this driver. One thing is that glTexSubImage2D() 
and glReadPixels() are HORRIBLY slow, another one is a crash in the fglrx 
driver somehow related to textures.

Maybe I can solve these 2 in time, so you don't have to write about them ;-)

Stefan

[Oliver Stieber]

--- Stefan Dösinger  wrote:
> Hello,
> > Oh yeah, another question-- are we making provision for 'special
> > circumstances'? I've got an ATI card, which makes me sensitive to such
> > things, since the ATI drivers fail to do many things that they should,
> > and often additional provisions need to be made specifically to get an
> > app or game to run with the stupid fglrx drivers, where no such config
> > workarounds need to be used with nVidia cards, or so I've heard. Or does
> > that just fall under 'Troubleshooting'? Or does Wine not need such
> > workarounds at all (unlike Cedega)?
>
> There are for sure some cases where fglrx-specific problems exist. I am 
> hunting two problems with this driver. One thing is that glTexSubImage2D() 
> and glReadPixels() are HORRIBLY slow, another one is a crash in the fglrx 
> driver somehow related to textures.
>
> Maybe I can solve these 2 in time, so you don't have to write about them ;-)

You need to turn on backbuffers / backingstore in your xf86config and those two functions were
reasonable fast (so long as you don't play mess around with the transfer modes) older driver
(can't renember which version)

Section "Device"
    Identifier                          "ATI Graphics Adapter"
    Driver                              "fglrx"
...
#    Backing store increases performance when locking the backbuffer
    Option "backingstore" "true"
...
EndSection

I've got a hack to go into wined3d that speeds up locking the backbuffer by not bothering to read
it if it's just been cleared, this get's movies using DirectX and backbuffer locking up to a good
frame rate with low CPU usage.

Oliver
> Stefan

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[Stefan Dösinger]

Hello,
> You need to turn on backbuffers / backingstore in your xf86config and those
> two functions were reasonable fast (so long as you don't play mess around
> with the transfer modes) older driver (can't renember which version)

Does this still work with newer drivers? 8.16.20 for example? It doesn't work 
for me.
(I don't understand this clearly from your sentence.)
> I've got a hack to go into wined3d that speeds up locking the backbuffer by
> not bothering to read it if it's just been cleared, this get's movies using
> DirectX and backbuffer locking up to a good frame rate with low CPU usage.

That's exactly the problem I have! I expect it to occur too when Empire Earth 
finally runs. Can you send me your hack? I'd like to try it with D3D7.

Another question: I've hit a problem where fglrx crashes on glBegin(GL_*) when 
GL_TEXTURE_2D is enabled. Any experiance / hints?

Thanks for this hint, it looks like you saved me from doing a time-intensive 
investigation!

Stefan

[Lionel Ulmer]

On Tue, Sep 20, 2005 at 10:56:41PM +0200, Stefan Dösinger wrote:
> That's exactly the problem I have! I expect it to occur too when Empire Earth 
> finally runs. Can you send me your hack? I'd like to try it with D3D7.

If the game is well behaved, this optimisation should already be present in
the D3D7 code (i.e. if the surface is locked 'write only', do not bother to
read the buffer from the card).

Alas most games are not well behaved and always lock in R/W mode :-)

Lionel

[Oliver Stieber]

--- Stefan Dösinger  wrote:
> Hello,
> > You need to turn on backbuffers / backingstore in your xf86config and those
> > two functions were reasonable fast (so long as you don't play mess around
> > with the transfer modes) older driver (can't renember which version)
>
> Does this still work with newer drivers? 8.16.20 for example? It doesn't work 
> for me.
> (I don't understand this clearly from your sentence.)

It stopped working a few driver versions ago gentoo only goes back as far as 8.14.13 and I don't
have a copy of any older drivers kicking around., I've sent a bug report to ATI, I hoped they'ed
fixed it as part of their performance improvements in 8.16.20 but apparently not.
> > I've got a hack to go into wined3d that speeds up locking the backbuffer by
> > not bothering to read it if it's just been cleared, this get's movies using
> > DirectX and backbuffer locking up to a good frame rate with low CPU usage.
>
> That's exactly the problem I have! I expect it to occur too when Empire Earth 
> finally runs. Can you send me your hack? I'd like to try it with D3D7.

I'm just about to put it into wined3d, I can have a look at backporting it to d3d7 but the idea is
to get d3d7 using wined3d at some point.

All you have to do is flag the backbuffer when it's cleared as cleared, and then at the end of a
drawing function flag the backbuffer as not cleared.
Then when you lock the backbuffer check the flag and if it's flagged as cleared just memset the
buffer to whatever the clear value is instead of doing a glReadPixels (most of the time you don't
need the memset because the buffer is going to be completely rewritten, on my home pc without the
hack I get about 10fps max with 100% CPU load, with the hack I get 30fps with about 30% CPU load)
> Another question: I've hit a problem where fglrx crashes on glBegin(GL_*) when 
> GL_TEXTURE_2D is enabled. Any experiance / hints?

Hmm.. I haven't had any problems with that yet, so long as I'm actually using GL_TEXTURE_2D  and
providing texture coordinates, in wined3d I disable any texture states that aren't used:

for (i = 0; i< GL_LIMITS(textures); ++i) {
        /* Bind the texture to the stage here */
        if (GL_SUPPORT(ARB_MULTITEXTURE)) {
            GLACTIVETEXTURE(i);
        }
                glDisable(GL_TEXTURE_1D);
                switch(This->stateBlock->textureDimensions[i]) {
                case GL_TEXTURE_2D:
                    glDisable(GL_TEXTURE_3D);
                    glDisable(GL_TEXTURE_CUBE_MAP_ARB);
                break;
                case GL_TEXTURE_3D:
                    glDisable(GL_TEXTURE_CUBE_MAP_ARB);
                    glDisable(GL_TEXTURE_2D);
                break;
                case GLTEXTURECUBEMAP:
                    glDisable(GL_TEXTURE_2D);
                    glDisable(GL_TEXTURE_3D);
                break;
> Thanks for this hint, it looks like you saved me from doing a time-intensive 
> investigation!
>
> Stefan

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[Stefan Dösinger]

Hello,
> I'm just about to put it into wined3d, I can have a look at backporting it
> to d3d7 but the idea is to get d3d7 using wined3d at some point.

That would be certainly interesting. Is wined3d ready for this yet? It would 
make much more sense to change this now instead of looking for bugs in D3D7 
when we know it will be removed in the not-so-far future.
> All you have to do is flag the backbuffer when it's cleared as cleared, and
> then at the end of a drawing function flag the backbuffer as not cleared.
> Then when you lock the backbuffer check the flag and if it's flagged as
> cleared just memset the buffer to whatever the clear value is instead of
> doing a glReadPixels (most of the time you don't need the memset because
> the buffer is going to be completely rewritten, on my home pc without the
> hack I get about 10fps max with 100% CPU load, with the hack I get 30fps
> with about 30% CPU load)

I'll look at this. Thanks
> Hmm.. I haven't had any problems with that yet, so long as I'm actually
> using GL_TEXTURE_2D  and providing texture coordinates, in wined3d I
> disable any texture states that aren't used:

Sounds interesting. I'll have a look.

Stefan

[Oliver Stieber]

--- Stefan Dösinger  wrote:
> Hello,
> > I'm just about to put it into wined3d, I can have a look at backporting it
> > to d3d7 but the idea is to get d3d7 using wined3d at some point.
>
> That would be certainly interesting. Is wined3d ready for this yet? It would 
> make much more sense to change this now instead of looking for bugs in D3D7 
> when we know it will be removed in the not-so-far future.

It's almost ready for DirectX 8 but there quite a bit of work intergrating things with ddraw
surfaces before DirectX 7 can be moved over.
> > All you have to do is flag the backbuffer when it's cleared as cleared, and
> > then at the end of a drawing function flag the backbuffer as not cleared.
> > Then when you lock the backbuffer check the flag and if it's flagged as
> > cleared just memset the buffer to whatever the clear value is instead of
> > doing a glReadPixels (most of the time you don't need the memset because
> > the buffer is going to be completely rewritten, on my home pc without the
> > hack I get about 10fps max with 100% CPU load, with the hack I get 30fps
> > with about 30% CPU load)
>
> I'll look at this. Thanks

http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
> > Hmm.. I haven't had any problems with that yet, so long as I'm actually
> > using GL_TEXTURE_2D  and providing texture coordinates, in wined3d I
> > disable any texture states that aren't used:
>
> Sounds interesting. I'll have a look.
>
> Stefan

___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

D3D7 -> WineD3D

[Stefan Dösinger]

Hello,
> It's almost ready for DirectX 8 but there quite a bit of work intergrating
> things with ddraw surfaces before DirectX 7 can be moved over.

I decided to give it a try without thinking for a long time, and I've made 
little progress: I've replaced the old OpenGL interface with a stub which is 
ready to take calls to WineD3D. I've noticed the following problems so far:

* Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check 
pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The 
thing compiles without errors or warnings now, but there may be side effects 
I don't know for now.

* Surfaces... You mentioned it, I think I don't need to explain anything 
here ;-)

* Not a problem, but a suggestion: Does it make sense to have DirectDraw using 
WineD3D? Without direct access to the video memory it's slow, and DGA has 
permission problems. Using WineD3D here might make surfaces less trouble, and 
it could give better performance without needing rw access to /dev/mem.
> http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html

I've seen it, but I've spent all my time hacking on D3D7->WineD3D

Stefan

D3D7 -> WineD3D

[Oliver Stieber]

--- Stefan Dösinger  wrote:
> Hello,
> > It's almost ready for DirectX 8 but there quite a bit of work intergrating
> > things with ddraw surfaces before DirectX 7 can be moved over.
>
> I decided to give it a try without thinking for a long time, and I've made 
> little progress: I've replaced the old OpenGL interface with a stub which is 
> ready to take calls to WineD3D. I've noticed the following problems so far:
> - Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check
>
> pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The 
> thing compiles without errors or warnings now, but there may be side effects 
> I don't know for now.

Where there is a difference between d3d8 and d3d9 headers a new type is created WINED3DFOOBAR and
put into include/wine/wined3dtypes.h, this should be easy enough to extend to d3d7.
> - Surfaces... You mentioned it, I think I don't need to explain anything
>
> here ;-)
> - Not a problem, but a suggestion: Does it make sense to have DirectDraw using
>
> WineD3D? Without direct access to the video memory it's slow, and DGA has 
> permission problems. Using WineD3D here might make surfaces less trouble, and 
> it could give better performance without needing rw access to /dev/mem.

That's defiantly a possibility but we'd still need to support people who don't have accelerated
OpenGL graphics. I think getting the DIB engine merge would be more beneficial.
> > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
>
> I've seen it, but I've spent all my time hacking on D3D7->WineD3D
>
> Stefan

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

D3D7 -> WineD3D

[Oliver Stieber]

--- Stefan Dösinger  wrote:
> - Not a problem, but a suggestion: Does it make sense to have DirectDraw using
>
> WineD3D? Without direct access to the video memory it's slow, and DGA has 
> permission problems. Using WineD3D here might make surfaces less trouble, and 
> it could give better performance without needing rw access to /dev/mem.

p.s. the reason for intergrating with ddraw is so that X11Drv works properly with wined3d, this
affects things like locking the mouse to a window in full screen mode and being able to Get and
Release the DC for the surface.
> > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
>
> I've seen it, but I've spent all my time hacking on D3D7->WineD3D

Great..

Oliver
> Stefan

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

D3D7 -> WineD3D

[Stefan Dösinger]

> > > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
> >
> > I've seen it, but I've spent all my time hacking on D3D7->WineD3D
>
> Great..

It's not so great at the moment, I've stopped trying for now. WineD3D and D3D7 
are too different to allow an easy translation between them. My plan was to 
copy some interfaces from d3d9 and use them to translate between d3d7 and 
wined3d, so I can use wined3d with the directx 9 interface, but I ended up 
with copying more and more code. I stopped when I tried to do something 
usefull with DD7 surfaces.

I didn't want to make huge changes into WineD3D, and I have to understand the 
way how newer Direct3D versions are working better.

Stefan

[Holly Bostick]

Oliver Stieber schreef:
> --- Stefan Dösinger  wrote:
> > Hello,
> > > Oh yeah, another question-- are we making provision for 'special 
> > > circumstances'? I've got an ATI card, which makes me sensitive to
> > > such things, since the ATI drivers fail to do many things that 
> > > they should, and often additional provisions need to be made 
> > > specifically to get an app or game to run with the stupid fglrx 
> > > drivers, where no such config workarounds need to be used with 
> > > nVidia cards, or so I've heard. Or does that just fall under 
> > > 'Troubleshooting'? Or does Wine not need such workarounds at all
> > >  (unlike Cedega)?
> >
> > There are for sure some cases where fglrx-specific problems exist.
> >  I am hunting two problems with this driver. One thing is that 
> > glTexSubImage2D() and glReadPixels() are HORRIBLY slow, another one
> >  is a crash in the fglrx driver somehow related to textures.
> >
> > Maybe I can solve these 2 in time, so you don't have to write about
> >  them ;-)
>
> You need to turn on backbuffers / backingstore in your xf86config and
>  those two functions were reasonable fast (so long as you don't play
>  mess around with the transfer modes) older driver (can't renember 
> which version)
>
> Section "Device" Identifier                          "ATI Graphics 
> Adapter" Driver                              "fglrx" ... #    Backing
>  store increases performance when locking the backbuffer Option 
> "backingstore" "true" ... EndSection
>
> I've got a hack to go into wined3d that speeds up locking the 
> backbuffer by not bothering to read it if it's just been cleared, 
> this get's movies using DirectX and backbuffer locking up to a good 
> frame rate with low CPU usage.

Thank you, Oliver and Stefan! I've changed my config (this option did
appear but was not only commented out, but in the wrong place in the
file, as well as having no value of either true or false). And my
impression is that it being commented is the default setting, but I'm
not sure about that.

I haven't restarted X yet, but it's good to know that this setting has
some function (that's why I think it's commented by default; I certainly
never knew what it did, so I most likely never messed with it), so it
can certainly go into my collection of 'miscellaneous technical notes
that might be useful'.

I hope that it won't be necessary to go into the docs, but you never
know what users might do (if the problems that come up on the user list
are any guide), what Wine they might be using, on what
even-less-supported-than-my-9800SE card (I'm thinking the Mobility
users, and the X*00 users) they might have on their systems. So any and
every little bit of info might be useful to somebody.

Assuming of course that if you successfully hunt down the issue and tell
the ATI team, they don't fix it themselves (which would be lovely,
wouldn't it?). Would save us all a lot of work....

Holly

[Kuba Ober]

> There's enough material on this topic to practically write a book.
> Someone should think about that.

Wouldn't such a book be mostly obsolete within a year of publication? That's 
almost like with those linux kernel development books: in 2 years timeframe 
they are mostly paperweights, unless you're interested only in 'big ideas' 
rather than details.

I might of course be wrong :)

Kuba

[Brian Vincent]

On 9/20/05, Kuba Ober  wrote:
> Wouldn't such a book be mostly obsolete within a year of publication? That's
> almost like with those linux kernel development books: in 2 years timeframe
> they are mostly paperweights, unless you're interested only in 'big ideas'
> rather than details.

Well, that's one of the things I wrestle with.  Some of the stuff is
just cool ideas that won't get outdated any time soon.  Some of it
will get outdated... and then the publisher can pay me for the second
addition.

Holly - I should also mention that you'll want to make sure you have
well-formed SGML when you write the docs, i.e. all opening tags must
have a closing tag.  I find xmllint and tidy are very helpful for
that.  tidy has easier output to understand, xmllint seems to be
pretty standard on distros these days.

-Brian

[Tom Wickline]

On 9/20/05, Holly Bostick  wrote:
> YES!!! Where do I sign up?

Hello Holly,

To get the docs in a terminal run :
cvs -z3 -d:pserver:[e-mail]:/cvsroot/wine co -P docs
When prompted for a password press the enter key.
A subdirectory named docs will be created. and you can edit to your
hearts content. ;)

Make sure you read over :
http://www.winehq.org/site/sending_patches

I put DOCS: at the beginning of the subject when sending this way Dimi
can easily
pick it out.

Tom
> Holly