Hey there... ]) powered by Linux 2.4.8 ([
I have discovered some strange behavior with WINE and Quicktime 5.0.x. As long as the "time slider" and the "audio bars" are being updated the video runs quite sluggish. But if you open a menu or a dialog box both the "time slider" and the "audio bars" stop updating - which is normal. BUT the video itself runs at full speed as long as both are not being updated. Which is kinda strange I guess. Even those animation content which is included with some movs doesn't slow the playback down, so it cannot be a performance issue. (on PIII with 500 Mhz, 256 MB ram and X 4.1.x (G400MAX))
Also if you maximize the video to full screen or anything that is not its original size, the playback also becomes very sluggish. Doesn't WINE use the XVideo protocol for such operations?
By the way. I am using yesterday's CVS checkout without any windows DLLs. I'll happily provide more informations - just let me know what you need.
Last but not least. All you guys are doing a great job -- and I wanted to take the opportunity to say THANK YOU to you all. :-)
-- So long, Matt ]) matthew2k@web.de, GPG key available at public keyservers ([
On Mon, Sep 10, 2001 at 01:34:05PM +0200, Matthias Dahl wrote:
Hey there... ]) powered by Linux 2.4.8 ([
I have discovered some strange behavior with WINE and Quicktime 5.0.x. As long as the "time slider" and the "audio bars" are being updated the video runs quite sluggish. But if you open a menu or a dialog box both the "time slider" and the "audio bars" stop updating - which is normal. BUT the video itself runs at full speed as long as both are not being updated. Which is kinda strange I guess. Even those animation content which is included with some movs doesn't slow the playback down, so it cannot be a performance issue. (on PIII with 500 Mhz, 256 MB ram and X 4.1.x (G400MAX))
Please check if after the patch I sent Saturday, which restricts blting to actually used rectangles and gives a rather good speed up to QuickTime here.
Also if you maximize the video to full screen or anything that is not its original size, the playback also becomes very sluggish.
Yes.
Doesn't WINE use the XVideo protocol for such operations?
It does not at this time.
I am currently working towards adding support for this.
Ciao, Marcus
On Mon, Sep 10, 2001 at 02:26:55PM +0200, Marcus Meissner wrote:
Please check if after the patch I sent Saturday, which restricts blting to actually used rectangles and gives a rather good speed up to QuickTime here.
I applied the patch but no change. The problem still occurs. Reminds me. Your patch is mostly (or even entirely) for the Direct Draw stuff. But I have that disabled here because the wine builtin support doesn't work too well for me.
With the builtin support enabled, the screen goes black as soon as I fire up for example Quicktime. It looks like something draws black over the whole screen because as soon as you cause X to redraw parts of the screen (by moving a window for example), you can clean up everything and use the window like a eraser. :-) Also the performance is really poor. :(
Things work a bit better if I copy the necessary Direct stuff over to my fake windows and let wine use native support. The black screen and such won't happen. Yet I get the best performance if I disable direct draw entirely. And if I open a window during quicktime playback (page setup for example) so that both the "time slider" and the "audio analyzer bars" stop updating, I get the same great performance like with a real windows system. Strange...
Are you using native or builtin direct draw? Does it work on your system? If it does, I should start wondering what's wrong with my setup here I guess.
Doesn't WINE use the XVideo protocol for such operations?
It does not at this time. I am currently working towards adding support for this.
That's great. Having wine use XV will be a really great advantage. If you do need a tester or something like that, let me know I'll happily volunteer. :-)
-- So long, Matt ]) matthew2k@web.de, GPG key available at public keyservers ([
On Mon, Sep 10, 2001 at 08:36:13PM +0200, Matthias Dahl wrote:
On Mon, Sep 10, 2001 at 02:26:55PM +0200, Marcus Meissner wrote:
Please check if after the patch I sent Saturday, which restricts blting to actually used rectangles and gives a rather good speed up to QuickTime here.
I applied the patch but no change. The problem still occurs. Reminds me. Your patch is mostly (or even entirely) for the Direct Draw stuff. But I have that disabled here because the wine builtin support doesn't work too well for me.
*sigh*
It works better with my patch, thats why I did it ;)
With the builtin support enabled, the screen goes black as soon as I fire up for example Quicktime. It looks like something draws black over the whole screen because as soon as you cause X to redraw parts of the screen (by moving a window for example), you can clean up everything and use the window like a eraser. :-) Also the performance is really poor. :(
Yes. DirectDraw was drawing over the whole screen for every frame displayed.
With my patch it does the full screen blt only once now, all others are restricted to the area it actually changes.
Things work a bit better if I copy the necessary Direct stuff over to my fake windows and let wine use native support. The black screen and such won't happen. Yet I get the best performance if I disable direct draw entirely. And if I open a window during quicktime playback (page setup for example) so that both the "time slider" and the "audio analyzer bars" stop updating, I get the same great performance like with a real windows system. Strange...
No. If you use ddraw=n it will (I think) not use DDRAW, but fall back to use DIB Sections.
Are you using native or builtin direct draw? Does it work on your system? If it does, I should start wondering what's wrong with my setup here I guess.
Builtin. The native version of DDRAW does not work to my knowledge.
Ciao, Marcus
On Fri, Sep 14, 2001 at 09:57:46AM +0200, Marcus Meissner wrote:
[... WINE DIRECT DRAW BUILTIN SUPPORT ...]
It works better with my patch, thats why I did it ;)
Strange. The builtin support just causes trouble here - and is way too slow. Even though the picture quality is somewhat better with it. *sigh*
No. If you use ddraw=n it will (I think) not use DDRAW, but fall back to use DIB Sections.
Right. And that results in windows-like performance - with the known problems I have stated earlier.
Builtin. The native version of DDRAW does not work to my knowledge.
The native support works - at least with DirectX 7.0a. Yet in my case the best solution is turn them both off. *pondering*
I will try a new CVS checkout and see if the problem still occurs. If it does, I hope (if you don't mind) we could try to track it down. What do you say?
-- So long, Matt ]) matthew2k@web.de, GPG key available at public keyservers ([
-
Marcus Meissner -
Marcus Meissner -
Matthias Dahl