Re: Updated DIB Engine

[Massimo Del Fedele]

Jesse Allen ha scritto:
> 
> The DIB engine is really unlikely to help starcraft the game at all.
> However, try staredit.exe ;)
> 
> Jesse
> 

The engine in its current state will, IMO, help just those apps that 
don't require real time graphics but do make many drawings on dibs, so 
requiring many conversions between dib itself and X11.
For example, apps with tons of text drawings on dibs will benefit 
greatly with the engine.
Optimizing blitting will increase the number of such apps.
Keep in mind that by now the blitting is a slow sequence of read 
pixel-convert format-write pixel, with no care if source and destination 
bitmaps have the same format, for example, which could be handled by 
simple memmove. It doesn't handle clipping, either, nor ROP operations.

For Autocad (with many TT fonts on drawing) the speed gain is something 
like 50x - 100x, depending on the amount of text objects I don't 
know staredit, but I'd like to know what is the speed increase :-)

Ciao

Max

Re: Updated DIB Engine

[Jesse Allen]

On Tue, Jan 27, 2009 at 12:29 PM, Reece Dunn  wrote:
> 2009/1/27 Massimo Del Fedele :
>> Any opinion about this one ? Could it be a good candidate for inclusion
>> in wine tree ?
>
> Hi,
>
> I have used this with StarCraft, running it with and without the DIB
> engine enabled. I find the environment variable makes it very easy to
> switch between them during testing, so I am for this (as well as being
> able to set the default option via the registry).
>
> My experience with the game is that it is actually slower and has a
> noticible stutter when compared to the non-DIB engine version. This
> does not mean that I am opposed to this going in, as I know that the
> blitting code is not yet optimised. In fact, I am for this to go in
> (provided that Alexandre accepts it).
>

The DIB engine is really unlikely to help starcraft the game at all.
However, try staredit.exe ;)

Jesse

Re: Updated DIB Engine

[Reece Dunn]

2009/1/27 Roderick Colenbrander :
>> 2009/1/27 Massimo Del Fedele :
>> > Any opinion about this one ? Could it be a good candidate for inclusion
>> > in wine tree ?
>>
>> I have used this with StarCraft, running it with and without the DIB
>> engine enabled. I find the environment variable makes it very easy to
>> switch between them during testing, so I am for this (as well as being
>> able to set the default option via the registry).
>>
>> My experience with the game is that it is actually slower and has a
>> noticible stutter when compared to the non-DIB engine version. This
>> does not mean that I am opposed to this going in, as I know that the
>> blitting code is not yet optimised. In fact, I am for this to go in
>> (provided that Alexandre accepts it).
>>
>
> In the end a dib engine will help a bit for StarCraft but for StarCraft the 
> only proper way for hardware acceleration is to use the ddraw-gl backend in 
> combination with the right rendertargetlockmode. Some games can really use a 
> DIB engine though and that are games like Age of Empires I and II. Though in 
> combination with a DIB engine more changes are needed for optimal performance 
> (e.g. allow the DIB engine to directly draw into a ddraw surface without a 
> memcpy)

Sure,

I wasn't expecting a speed boost here, because the implementation is
essentially a proof of concept - hence me saying that the blitting
code was not optimised .

The game was functional; no noticible visual regressions, which is
good. I haven't done any more testing yet.

Another thing this should improve is the theme rendering for
alpha-blended images, but likely not at the moment.

- Reece

Re: Updated DIB Engine

[Roderick Colenbrander]

> 2009/1/27 Massimo Del Fedele :
> > Any opinion about this one ? Could it be a good candidate for inclusion
> > in wine tree ?
> 
> Hi,
> 
> I have used this with StarCraft, running it with and without the DIB
> engine enabled. I find the environment variable makes it very easy to
> switch between them during testing, so I am for this (as well as being
> able to set the default option via the registry).
> 
> My experience with the game is that it is actually slower and has a
> noticible stutter when compared to the non-DIB engine version. This
> does not mean that I am opposed to this going in, as I know that the
> blitting code is not yet optimised. In fact, I am for this to go in
> (provided that Alexandre accepts it).
> 

In the end a dib engine will help a bit for StarCraft but for StarCraft the 
only proper way for hardware acceleration is to use the ddraw-gl backend in 
combination with the right rendertargetlockmode. Some games can really use a 
DIB engine though and that are games like Age of Empires I and II. Though in 
combination with a DIB engine more changes are needed for optimal performance 
(e.g. allow the DIB engine to directly draw into a ddraw surface without a 
memcpy)

Roderick
-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: Updated DIB Engine

[Austin English]

On Tue, Jan 27, 2009 at 1:51 PM, Massimo Del Fedele  wrote:
> Reece Dunn ha scritto:
>> 2009/1/27 Massimo Del Fedele :
>>> Any opinion about this one ? Could it be a good candidate for inclusion
>>> in wine tree ?
>>
>> Hi,
>>
>> I have used this with StarCraft, running it with and without the DIB
>> engine enabled. I find the environment variable makes it very easy to
>> switch between them during testing, so I am for this (as well as being
>> able to set the default option via the registry).
>
> Thanx, that was what I wanted to have :-)
>>
>> My experience with the game is that it is actually slower and has a
>> noticible stutter when compared to the non-DIB engine version. This
>> does not mean that I am opposed to this going in, as I know that the
>> blitting code is not yet optimised. In fact, I am for this to go in
>> (provided that Alexandre accepts it).
>
> Yep, the blitting code is just a "placeholder" to make most apps run,
> not an optimized one. Making it optimized is trivial but requires many
> code lines, so before proceeding I thought to wait for "approval" of the
> way the engine is done. The same is for text stuffs.
>>
>> The only thing I would say is to break it up. For example, there are
>> bits that you have taken from Jesse and Huw's efforts that are various
>> isolated patches. These should be sent in a git patch format so that
>> the authors can be attributed in the Wine git tree as well as being in
>> the Copyright notices.
>
> Well, that one could be only partially done, because I modified most of
> both Huw and Jesse's code. I let Jesse and Huw's copyright notices
> because of that, but going back from original code, joining the 2 and
> adding my mods by mean of many git patches would be overkilling.
> Even more, both trees were somehow outdated in respect to actual wine
> tree, so the automatic merge didn't work for some parts of code.
> I'd see easier to put the 3 names on each patch when (if) merged with
> main tree.
>
>  Aside from that, if you could break the DIB
>> patch into smaller logical chunks it will be easier to review and get
>> the patches in.
>
> Well, that also can be partially done :
>
> 1- First GDI32 patch, the one that allows to insert DIB Driver, without
> blitting (mostly from Huw's tree, but driver loading displaced from
> SelectBitmap to CreateDC by me, with some additions to avoid crashes if
> driver is not present.
> 2 - Starting dib engine, without blitting and (maybe) many stubs, but
> with primitives and some basic stuffs, mostly from Huw's tree, some
> small patches by me
> 3 - Blitting, which requires both patching GDI32 again and adding the
> code to DIB driver, and all stubs; all that mostly from Jesse's tree,
> many patches by me
> 4 - Initial text and font implementation, by me
> 5 - Registry and environment variable stuffs, by me
>
> Most chunks need to span over more source files.
> After that, I guess the code is defined enough to be opened for completion.
>>
>> Have you asked Alexandre on IRC what he thinks of the design?
>>
> No I'm not using IRC since ages :-)
> Is this the way to ask him ?

He's usually on IRC, nickname julliard.

Though, to be frank, his lack of response to the e-mails leads me to
believe either:
A) He doesn't like the design.
B) Is really busy, and hasn't had time to look it thoroughly.
C) Both.

-- 
-Austin

Re: Updated DIB Engine

[Massimo Del Fedele]

Reece Dunn ha scritto:
> 2009/1/27 Massimo Del Fedele :
>> Any opinion about this one ? Could it be a good candidate for inclusion
>> in wine tree ?
> 
> Hi,
> 
> I have used this with StarCraft, running it with and without the DIB
> engine enabled. I find the environment variable makes it very easy to
> switch between them during testing, so I am for this (as well as being
> able to set the default option via the registry).

Thanx, that was what I wanted to have :-)
> 
> My experience with the game is that it is actually slower and has a
> noticible stutter when compared to the non-DIB engine version. This
> does not mean that I am opposed to this going in, as I know that the
> blitting code is not yet optimised. In fact, I am for this to go in
> (provided that Alexandre accepts it).

Yep, the blitting code is just a "placeholder" to make most apps run, 
not an optimized one. Making it optimized is trivial but requires many 
code lines, so before proceeding I thought to wait for "approval" of the 
way the engine is done. The same is for text stuffs.
> 
> The only thing I would say is to break it up. For example, there are
> bits that you have taken from Jesse and Huw's efforts that are various
> isolated patches. These should be sent in a git patch format so that
> the authors can be attributed in the Wine git tree as well as being in
> the Copyright notices.

Well, that one could be only partially done, because I modified most of 
both Huw and Jesse's code. I let Jesse and Huw's copyright notices 
because of that, but going back from original code, joining the 2 and 
adding my mods by mean of many git patches would be overkilling.
Even more, both trees were somehow outdated in respect to actual wine 
tree, so the automatic merge didn't work for some parts of code.
I'd see easier to put the 3 names on each patch when (if) merged with 
main tree.

  Aside from that, if you could break the DIB
> patch into smaller logical chunks it will be easier to review and get
> the patches in.

Well, that also can be partially done :

1- First GDI32 patch, the one that allows to insert DIB Driver, without 
blitting (mostly from Huw's tree, but driver loading displaced from 
SelectBitmap to CreateDC by me, with some additions to avoid crashes if 
driver is not present.
2 - Starting dib engine, without blitting and (maybe) many stubs, but 
with primitives and some basic stuffs, mostly from Huw's tree, some 
small patches by me
3 - Blitting, which requires both patching GDI32 again and adding the 
code to DIB driver, and all stubs; all that mostly from Jesse's tree, 
many patches by me
4 - Initial text and font implementation, by me
5 - Registry and environment variable stuffs, by me

Most chunks need to span over more source files.
After that, I guess the code is defined enough to be opened for completion.
> 
> Have you asked Alexandre on IRC what he thinks of the design?
> 
No I'm not using IRC since ages :-)
Is this the way to ask him ?

> - Reece
> 
Ciao and thanx for comments !

Max

Re: Updated DIB Engine

[Reece Dunn]

2009/1/27 Massimo Del Fedele :
> Any opinion about this one ? Could it be a good candidate for inclusion
> in wine tree ?

Hi,

I have used this with StarCraft, running it with and without the DIB
engine enabled. I find the environment variable makes it very easy to
switch between them during testing, so I am for this (as well as being
able to set the default option via the registry).

My experience with the game is that it is actually slower and has a
noticible stutter when compared to the non-DIB engine version. This
does not mean that I am opposed to this going in, as I know that the
blitting code is not yet optimised. In fact, I am for this to go in
(provided that Alexandre accepts it).

The only thing I would say is to break it up. For example, there are
bits that you have taken from Jesse and Huw's efforts that are various
isolated patches. These should be sent in a git patch format so that
the authors can be attributed in the Wine git tree as well as being in
the Copyright notices. Aside from that, if you could break the DIB
patch into smaller logical chunks it will be easier to review and get
the patches in.

Have you asked Alexandre on IRC what he thinks of the design?

- Reece

Re: Updated DIB Engine

[Massimo Del Fedele]

Any opinion about this one ? Could it be a good candidate for inclusion 
in wine tree ?

Ciao

Max

Re: Updated DIB Engine

[Massimo Del Fedele]

Erich Hoover ha scritto:
> 
> What I was trying to say is if you could have something like this for 
> all the stubs:
> 
> BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT 
> widthDst, INT heightDst,
> DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT 
> widthSrc, INT heightSrc,
> BLENDFUNCTION blendfn)
> {
> FIXME("reverting to slow behavior!\n");
> return TheOldBehavior->AlphaBlend(...);
> }
> 
> 
> While I'm obviously not greatly familiar with this code, it seems like 
> the engine would have a better chance of being successful if 
> unimplemented features fell back to the old behavior.  It seems like 
> that would allow you to gradually transition over to the integrated DIB 
> engine a little bit at a time, rather than having a lot of unavailable 
> features that would all need to be implemented before the integrated DIB 
> engine could be turned on for everyone.  Even if you had to create a 
> special surface and copy the bitmap back and forth every time you had to 
> revert to the old behavior it seems like it would at least provide a 
> good testbed.
> 
> Erich Hoover
> ehoo...@mines.edu 
> 
> 
>

Well... almost impossible by keeping GDI and driver structure separated.
You call winex11 whith its physDev, and WineDib with it's own 
(different) physDev. Either don't have knowledge of other's structure 
(they're opaque pointers), nor they have e pointer of each other.
So, from Dib driver is impossible to call an x11 driver function.
That could be done directly from inside GDI32, but would require some 
deep changes on it, which I wanted to avoid.
BTW, I'm still thinking that the "better" way of adding the dib engine 
would be from inside gdi32, but whis would mean to change deeply a code 
that is working good.
Another possibility would be to add a pointer to x11 physDev inside the 
Dib physDev that one would be easier, but hacky.

Ciao

Max

Re: Updated DIB Engine

[Erich Hoover]

On Sun, Jan 25, 2009 at 11:25 AM, Massimo Del Fedele  wrote:

> Erich Hoover ha scritto:
> >
> > I haven't looked into your implementation in much detail (I need more
> > hours in a day, I swear), but would it be possible to pass all the stubs
> > on so that unimplemented functionality still works even if it's dog
> > slow?  It'd be nice if we could take advantage of the implemented
> > features, still be able to handle everything, and then spew a "FIXME:
> > Help Wine run faster by implementing this function in the DIB engine!"
> > for features that are not handled yet.  (yeah, yeah, I want my cake and
> > be able to eat it too)
> >
> > Erich Hoover
> > ehoo...@mines.edu 
> >
>
> Well, by now many functions are stubbed (with disabled FIXMEs for
> speed), and 3 apps I've tested on it works ok.
> Some bad graphics, but mostly usable.
> You can test it easily and, if you like, you can enable all the stubs
> FIXMEs uncommenting a #define on header file.
>
> Ciao
>
> Max
>
>
What I was trying to say is if you could have something like this for all
the stubs:

BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT
widthDst, INT heightDst,
DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT
widthSrc, INT heightSrc,
BLENDFUNCTION blendfn)
{
FIXME("reverting to slow behavior!\n");
return TheOldBehavior->AlphaBlend(...);
}


While I'm obviously not greatly familiar with this code, it seems like the
engine would have a better chance of being successful if unimplemented
features fell back to the old behavior.  It seems like that would allow you
to gradually transition over to the integrated DIB engine a little bit at a
time, rather than having a lot of unavailable features that would all need
to be implemented before the integrated DIB engine could be turned on for
everyone.  Even if you had to create a special surface and copy the bitmap
back and forth every time you had to revert to the old behavior it seems
like it would at least provide a good testbed.

Erich Hoover
ehoo...@mines.edu

Re: Updated DIB Engine

[Massimo Del Fedele]

Erich Hoover ha scritto:
> 
> I haven't looked into your implementation in much detail (I need more 
> hours in a day, I swear), but would it be possible to pass all the stubs 
> on so that unimplemented functionality still works even if it's dog 
> slow?  It'd be nice if we could take advantage of the implemented 
> features, still be able to handle everything, and then spew a "FIXME: 
> Help Wine run faster by implementing this function in the DIB engine!" 
> for features that are not handled yet.  (yeah, yeah, I want my cake and 
> be able to eat it too)
> 
> Erich Hoover
> ehoo...@mines.edu 
> 

Well, by now many functions are stubbed (with disabled FIXMEs for 
speed), and 3 apps I've tested on it works ok.
Some bad graphics, but mostly usable.
You can test it easily and, if you like, you can enable all the stubs 
FIXMEs uncommenting a #define on header file.

Ciao

Max

Re: Updated DIB Engine

[Erich Hoover]

On Sun, Jan 25, 2009 at 10:23 AM, Massimo Del Fedele  wrote:

> ...IMHO the engine will (if it ever enters on main trunk) stay
> disabled
> by default for long, long time. Having it to work ok to the same extent
> as is gdi32/winex11 now will take a lot of time and patches.
> ...
>

I haven't looked into your implementation in much detail (I need more hours
in a day, I swear), but would it be possible to pass all the stubs on so
that unimplemented functionality still works even if it's dog slow?  It'd be
nice if we could take advantage of the implemented features, still be able
to handle everything, and then spew a "FIXME: Help Wine run faster by
implementing this function in the DIB engine!" for features that are not
handled yet.  (yeah, yeah, I want my cake and be able to eat it too)

Erich Hoover
ehoo...@mines.edu

Re: Updated DIB Engine

[Massimo Del Fedele]

Roderick Colenbrander ha scritto:
>>
> 
> Having an environment variable is a minor detail. Sure it should 
be used transparently but it will take a lot of time (when the 
architecture is correct)
to enable it by default.

IMHO the engine will (if it ever enters on main trunk) stay disabled 
by default for long, long time. Having it to work ok to the same extent 
as is gdi32/winex11 now will take a lot of time and patches.

A lot of performance tuning would be needed as it could seriously
decrease performance in a lot of cases.

I agree completely on this

The gain / loss depends on what type of calls the program is making.
If it draws lets say on a line by line basis then software rendering 
could help.
But if it uses a smarter method a single X call might be more efficient.

More precisely, it will depend on the degree of optimization of dib 
engine code which, by now, is close to zero. When blitting will be 
optimized, for example, the performance increase will be huge.

Further there are also other tradeoffs e.g. when the latest version of 
the drawable is in X then
it might not be smart at all to copy it back to the DIB engine and let 
it do the rendering
just because we have a DIB engine.
The cost for the download and reupload to the videocard might be much 
higher.

The engine, as it is now, just renders on DIBs, when they're in memory, 
not on DDB. So it shouldn't penalize at all the rendering of drawables 
already owned by X. It'll just avoid the double copy between dib and x 
ant the way back just to, for example, render some text. That happens 
now in autocad, for example, which slows it down by a factor off 100.
The only "mixed" behaviour is when you're blitting a dib onto a ddb (or 
the way around), but even then the code converts the source bitmap to 
the destination format and then uses the best way to blit it.
It could even be optimized by blitting without converting before, but it 
would need some hard intervention on GDI code, which is what I wanted to 
avoid.

Ciao


Max

Re: Updated DIB Engine

[Massimo Del Fedele]

Ben Klein ha scritto:
> 
> I'm still opposed to adding an environment variable for something so
> simple (an enable/disable flag). It just seems like extra work for no
> benefit to me. I'm sure we can all agree that the registry is a
> suitable place for the setting.

The environment variable allows testing on the fly of enabled/disabled 
engine, AND allows to run some apps with engine enabled as others with 
engine disabled. Having to run regedit just to test an app run is 
overkilling, IMHO.
BTW, the environment variable is fully optional, you can but you haven't 
to use it, if you choose so. just set the registry variable and all is ok.

> 
> Isn't the idea that the DIB engine will only be used as needed, and
> will be good in all cases where it's used? If that's the case, it's
> not too important having on-the-fly per-application enabling/disabling
> (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
> 

The engine, as it is, is by far less than complete, so very few apps do 
benefit of it, one of them is autocad, at the moment. I guess most apps 
are penalized by the engine in present state.
So I really don't see the point of avoiding an environment var which, 
BTW, is checked just ONCE and on first loading of the DIB driver, and 
costs just about 5 lines of code.

Max

Re: Updated DIB Engine

[Roderick Colenbrander]

> 2009/1/25 Massimo Del Fedele :
> > The engine is disabled by default; can be changed by environment
> variable :
> >
> > export WINEDIB=ON (or ENABLE or ENABLED or TRUE)  enables it
> > export WINEDIB=OFF (or DISABLE or DISABLED or FALSE)  disables it
> >
> > or by registry key :
> >
> > HKCU/Software/Wine/DIB Engine/Enable='Y'  enables it
> > HKCU/Software/Wine/DIB Engine/Enable='N'  disables it
> >
> > the environment variable has precedence on registry, so for example if
> > WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is
> > enabled.
> >
> > I suggest to use the environment for the moment, at less you have an app
> > that runs much better with the engine (autocad, for example...) which
> > benefits from a default enabled engine in registry.
> 
> I'm still opposed to adding an environment variable for something so
> simple (an enable/disable flag). It just seems like extra work for no
> benefit to me. I'm sure we can all agree that the registry is a
> suitable place for the setting.
> 
> Isn't the idea that the DIB engine will only be used as needed, and
> will be good in all cases where it's used? If that's the case, it's
> not too important having on-the-fly per-application enabling/disabling
> (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
> 

Having an environment variable is a minor detail. Sure it should be used 
transparently but it will take a lot of time (when the architecture is correct) 
to enable it by default. A lot of performance tuning would be needed as it 
could seriously decrease performance in a lot of cases. The gain / loss depends 
on what type of calls the program is making. If it draws lets say on a line by 
line basis then software rendering could help. But if it uses a smarter method 
a single X call might be more efficient. Further there are also other tradeoffs 
e.g. when the latest version of the drawable is in X then it might not be smart 
at all to copy it back to the DIB engine and let it do the rendering just 
because we have a DIB engine. The cost for the download and reupload to the 
videocard might be much higher.

Roderick
-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: Updated DIB Engine

[Ben Klein]

2009/1/25 Massimo Del Fedele :
> The engine is disabled by default; can be changed by environment variable :
>
> export WINEDIB=ON (or ENABLE or ENABLED or TRUE)  enables it
> export WINEDIB=OFF (or DISABLE or DISABLED or FALSE)  disables it
>
> or by registry key :
>
> HKCU/Software/Wine/DIB Engine/Enable='Y'  enables it
> HKCU/Software/Wine/DIB Engine/Enable='N'  disables it
>
> the environment variable has precedence on registry, so for example if
> WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is
> enabled.
>
> I suggest to use the environment for the moment, at less you have an app
> that runs much better with the engine (autocad, for example...) which
> benefits from a default enabled engine in registry.

I'm still opposed to adding an environment variable for something so
simple (an enable/disable flag). It just seems like extra work for no
benefit to me. I'm sure we can all agree that the registry is a
suitable place for the setting.

Isn't the idea that the DIB engine will only be used as needed, and
will be good in all cases where it's used? If that's the case, it's
not too important having on-the-fly per-application enabling/disabling
(whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).