10 Sep
2001
10 Sep
'01
11:34 a.m.
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(a)web.de, GPG key available at public keyservers ([
10 Sep
10 Sep
12:26 p.m.
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
6:36 p.m.
On Mon, Sep 10, 2001 at 02:26:55PM +0200, Marcus Meissner wrote:
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(a)web.de, GPG key available at public keyservers ([
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. 
14 Sep
14 Sep
7:57 a.m.
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:
*sigh*
It works better with my patch, thats why I did it ;)
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. :(
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
20 Sep
20 Sep
11:03 a.m.
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(a)web.de, GPG key available at public keyservers ([
8277
days inactive
8287
days old
4 comments
3 participants
participants (3)
-
Marcus Meissner -
Marcus Meissner -
Matthias Dahl