Slow emulation of StretchBlt

[andrea]

Hi,

I am looking at the performance of AppleWin (a 32 bit app) in Wine and have come across this 
function StretchBlt which seems to be much slower in Wine that in Windows 10.

The call looks like this

			StretchBlt(
				hFrameDC,
				xdest, ydest,
				wdest, hdest,
				g_hDeviceDC,
				xSrc, ySrc,
				FRAMEBUFFER_BORDERLESS_W, FRAMEBUFFER_BORDERLESS_H,
				SRCCOPY);

With typical values

		xdest	0	int
		ydest	0	int
		wdest	1120	int
		hdest	768	int
		xSrc	22	int
		ySrc	17	int

	#define  FRAMEBUFFER_BORDERLESS_W 560
	#define  FRAMEBUFFER_BORDERLESS_H 384

In Wine they take 20x the time in Windows 10 (running inside a VirtualBox).
The consequence is CPU utilisation 20x higher in Wine than Windows.

I am running wine 2.5 in a 64 bit Fedora 25 machine.

Does this ring any bell?

Andrea

[Roderick Colenbrander]

Depending on source, destination format and some other things it may
get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
picked, it could be that your drivers are not accelerating this
situation.

On Mon, Apr 17, 2017 at 8:29 AM, andrea <mariofutire(a)googlemail.com> wrote:
> Hi,
>
> I am looking at the performance of AppleWin (a 32 bit app) in Wine and have
> come across this function StretchBlt which seems to be much slower in Wine
> that in Windows 10.
>
> The call looks like this
>
> StretchBlt(
>                                 hFrameDC,
>                                 xdest, ydest,
>                                 wdest, hdest,
>                                 g_hDeviceDC,
>                                 xSrc, ySrc,
>                                 FRAMEBUFFER_BORDERLESS_W,
> FRAMEBUFFER_BORDERLESS_H,
>                                 SRCCOPY);
>
> With typical values
>
> xdest   0       int
>                 ydest   0       int
>                 wdest   1120    int
>                 hdest   768     int
>                 xSrc    22      int
>                 ySrc    17      int
>
> #define  FRAMEBUFFER_BORDERLESS_W 560
>         #define  FRAMEBUFFER_BORDERLESS_H 384
>
> In Wine they take 20x the time in Windows 10 (running inside a VirtualBox).
> The consequence is CPU utilisation 20x higher in Wine than Windows.
>
> I am running wine 2.5 in a 64 bit Fedora 25 machine.
>
> Does this ring any bell?
>
> Andrea

[Andrea]

On 18/04/17 06:05, Roderick Colenbrander wrote:
> Depending on source, destination format and some other things it may
> get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
> picked, it could be that your drivers are not accelerating this
> situation.

Is there a way to check this?
It is accelerated by Windows inside VBox on the same hardware.

I have a Haswell i5, and running mesa 13.0.4
> On Mon, Apr 17, 2017 at 8:29 AM, andrea <mariofutire(a)googlemail.com> wrote:
> > Hi,
> >
> > I am looking at the performance of AppleWin (a 32 bit app) in Wine and have
> > come across this function StretchBlt which seems to be much slower in Wine
> > that in Windows 10.

[Huw Davies]

On Mon, Apr 17, 2017 at 10:05:37PM -0700, Roderick Colenbrander wrote:
> Depending on source, destination format and some other things it may
> get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
> picked, it could be that your drivers are not accelerating this
> situation.

By default this won't happen and the stretching will be done in the
dibdrv.  If you're running with the X11 driver, you could try adding
the registry key

[HKCU\\Software\\Wine\\X11 Driver]
"ClientSideGraphics"="N"

Huw.

[Andrea]

On 19/04/17 12:03, Huw Davies wrote:
> On Mon, Apr 17, 2017 at 10:05:37PM -0700, Roderick Colenbrander wrote:
> > Depending on source, destination format and some other things it may
> > get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
> > picked, it could be that your drivers are not accelerating this
> > situation.
>
> By default this won't happen and the stretching will be done in the
> dibdrv.  If you're running with the X11 driver, you could try adding
> the registry key
>
> [HKCU\\Software\\Wine\\X11 Driver]
> "ClientSideGraphics"="N"
>
> Huw.

It does indeed make a difference.

CPU usage goes from 25% to 15%

I will look at the next bottleneck.
Is there any drawback to setting N always?

Regards

[Andrea]

On 19/04/17 12:03, Huw Davies wrote:
> On Mon, Apr 17, 2017 at 10:05:37PM -0700, Roderick Colenbrander wrote:
> > Depending on source, destination format and some other things it may
> > get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
> > picked, it could be that your drivers are not accelerating this
> > situation.
>
> By default this won't happen and the stretching will be done in the
> dibdrv.  If you're running with the X11 driver, you could try adding
> the registry key
>
> [HKCU\\Software\\Wine\\X11 Driver]
> "ClientSideGraphics"="N"
>
> Huw.

When you say
> If you're running with the X11 driver

What else could I be running?
Is there a better driver?

[Michael Stefaniuc]

On 04/22/2017 04:28 PM, Andrea wrote:
> On 19/04/17 12:03, Huw Davies wrote:
> > On Mon, Apr 17, 2017 at 10:05:37PM -0700, Roderick Colenbrander wrote:
> > > Depending on source, destination format and some other things it may
> > > get accelerated e.g. by winex11.drv to xrender. Assuming xrender is
> > > picked, it could be that your drivers are not accelerating this
> > > situation.
> >
> > By default this won't happen and the stretching will be done in the
> > dibdrv.  If you're running with the X11 driver, you could try adding
> > the registry key
> >
> > [HKCU\\Software\\Wine\\X11 Driver]
> > "ClientSideGraphics"="N"
> >
> > Huw.
>
> When you say
> > If you're running with the X11 driver
>
> What else could I be running?
> Is there a better driver?
> The Mac driver on Mac OS X.

bye
	michael